> The following patch implements a new special variable, > @{^COMPILE_SCOPE_CONTAINER}, which allows implementing the behaviour required > by the current users of the %^H + Scope::Guard and B::Hooks::EndOfScope users. I'm all in favour of this change. Another suggestion was to make ${^COMPILE_SCOPE_CONTAINER}[0] a reference to the @{^COMPILE_SCOPE_CONTAINER} of the previous scope instead of copying the previous values in the new array. I would have loved this too, but Florian said on IRC that it feared it would be more difficult to implement. I personnaly think it'd be just as simple as pushing a ref in the array and that the sole nature of the feature would ensure that the refcounts are correctly handled. Does someone think it'd make a valuable addition that it worths to spend some time researching? >> Oh, snap! I'm just in the middle of writing a more general solution to >> the same problem, which I've currently got at >> http://github.com/mauzo/perl/tree/blocks . My idea was not to use a >> special variable, but rather a new special block, SCOPECHECK, which gets >> called at the end of compiling the current scope. My intention was to >> implement ENTER/LEAVE/&c. from Perl 6 at the same time. >> > > I'm glad to see I'm not the only one fighting against this problem. > > I don't know which approach would be better. However, I must note that a > variable offers some kind of introspection for data attached to a scope > during its compile time. How that is useful is also demonstrated by the > test, which is part of my patch. > I prefer the variable approach because not only it provides some means of introspection, but also because it's easier to conditionnaly store a destructor that way than with a block. Finally, adding a new variable is just much simpler to implement. The new control blocks from Perl 6 would definitely make a great addition to Perl 5, but they're a different issue that the dynamic scope end one. Vincent.Thread Previous | Thread Next