Front page | perl.perl5.porters |
Postings from July 2009
G'day Nicholas,
Nicholas Clark wrote:
> If I understand you correctly, the problem isn't that autodie needs to do
> more than %^H currently does. You don't just need something *lexical* to hang
> state in that can be introspected at compile time.
>
> You also need some mechanism to run a *dynamic* end-of-scope hook at compile
> time?
Yes, this is exactly what autodie (and anything else using
B::Hooks::EndOfScope) needs.
> It was not reported at any time in the 3 years between when it was added to
> blead and when blead shipped as 5.10
>
> This report of a possible bug is a bit late.
I agree, it's very late! Until now, I don't think anyone noticed this was
actually a problem. What worked in 5.8.x continued to work in 5.10.x.
String evals are, well, not always the right way of doing things. As such,
the amount of code that used lexical triggers via %^H next to string evals
were very rare.
Luckily...
> This behaviour was never a documented part of the implementation.
> It IS NOT NOW.
The 'perlpragma.pod' file, which talks about %^H in depth, says one
shouldn't store anything but simple strings and integers in %^H, because
anything else will get stringified. So the stringification *is* documented,
it's just the timing that isn't.
While I agree that using %^H in this way is an accidental feature, we can
fix the problem that has just been encountered by:
1) Upon string eval, we shallow copy %^H. We already do this.
2) Immediately stringify the values in the copied %^H and store them.
We currently appear to do this much later (just before run-time?)
With these changes, code relying upon ref-counts in %^H to trigger magic
will continue to work as they did in 5.8.x. Code using %^H to store
string/integer hints will also continue to work. Lexical pragmas (using
both the accidental and intentional features) can continue to access %^H
within string evals. I can't think of any immediate downsides.
AFAIK inside string evals the version of %^H which is available contains the
stringified values anyway. It's just that we currently stringify them
rather late.
Going forward, finding a better solution that doesn't depend upon accidental
features is going to be preferable. I honestly don't know what that
solution should be. It could involve turning %^H's behaviour into an
intentional feature. It could involve providing a different hook entirely.
Luckily, most of the code using %^H for this purpose uses
B::Hooks::EndOfScope for the heavy lifting, so most uses can be updated by
changing a single module.
All the best,
Paul
--
Paul Fenwick <pjf@perltraining.com.au> | http://perltraining.com.au/
Director of Training | Ph: +61 3 9354 6001
Perl Training Australia | Fax: +61 3 9354 2681
Thread Previous
|
Thread Next