On Thu Apr 19 03:36:31 2012, BOBTFISH wrote:
Show quoted text>
> On 19 Apr 2012, at 02:19, Father Chrysostomos via RT wrote:
> > On Wed Apr 18 18:53:30 2012, BOBTFISH wrote:
> >> On Wed Apr 18 17:16:55 2012, SPROUT wrote:
> >>> Catalyst sets up the code in question to run on_scope_end. That
> means
> >>> the end of the code
> >>> that is currently compiling.
> >>
> >> Not true.
> >>
> >> You can (ab)use this at runtime to mean on block end.
> >
> > Um, I’ve read the source for B::Hooks::EndOfScope and the
> corresponding perl source. I know
> > what I’m talking about. :-)
>
> Apologies for coming across as trying to correct you! That was not the
> intention - you've assuredly got a much better understanding of how
> this actually works, or doesn't work then me - I'm only noting the
> observed effects.
>
> > In 5.16 on_scope_end ends up meaning end of the compile time of the
> block containing the
> > currently-running BEGIN block.
> >
> > In earlier versions it means the same or the end of the current
> string eval’s run time,
> > depending on whether BEGIN or eval "" is closer to the top of the
> call stack.
>
> Can I trouble you to explain how/why then the hook fires in earlier
> perls ? As the explanation above implies to me that this would
> never have worked.…
Don’t forget that a required file is a type of string eval. So string eval scope ends up
meaning file scope in that case.
Show quoted text> > Scope::Upper can already do that, if I understand both modules
> correctly (I just glanced at
> > hook-endofruntime quickly).
>
> Catalyst previously used Scope::Upper for this (at least briefly - I'm
> not sure it ever made it to a production release).
>
> However (if I remember correctly - which I may not do), it was too
> sensitive to block level changes (i.e. if you wrote { __PACKAGE__-
> >setup } in your app, it'd fire at the end of the block, not end of
> file).
>
> I would guess that you're right, and that Hook::EndOfRuntime is likely
> to cause the same issues.
In either case, you can specify how many levels up to go. (caller $num)[7] can be used to
determine which frame is a require().
Show quoted text> I'd like to be confident we know about exactly why the B::Hooks::EOS
> stops working in blead (I believe rafl may have raised a perlbug
> for this, but I'm unsure the # - I've followed up with him, and
> I'll link it in when I know the # / if I'm right).
It still works, but, as I said, it works for compile-time scopes, rather than compile-time +
string-eval-run-time scopes.
Show quoted text> I also have a branch in Catalyst which fixes this in a much less
> insane manor - by copying the Moose::Object::new method into each
> plugin as it's loaded - avoiding any possibility of the
> Class::Accessor(::Fast)? new method from being lowest in the
> inheritance hierarchy. This means that we no longer require any
> ::Hooks?:: module, so whilst a pretty gross hack - it's less
> completely insane and should be much more predictable in future.
>
> This, however, implies a significant slowdown for Catalyst apps which
> don't manually make themselves immutable - so I'm going to look
> into restoring the immutable behaviour at a later point (when the
> app is told to run, rather than at end of compile time) to correct
> this. In the worst case, even if this doesn't work out - I'm pretty
> confident we'll be able to ship a fixed version which doesn't rely
> on the fragile behaviour in the next few days.
I don’t know enough about Moose or Catalyst to understand exactly what the fix-up is for
here. So I cannot comment on that.
