Front page | perl.perl5.porters |
Postings from July 2009
On Sun, Jul 05, 2009 at 02:50:02PM +1000, Paul Fenwick wrote:
> I've been very careful to code autodie with no mandatory dependencies at
> all, and I've also been careful to keep autodie as pure Perl. However I
> can't see any way of getting around this bug without using a dependency or
> writing XS, and I'm not good at XS.
However, you're mailing a list which probably has the higest concentration
of XS knowledge, so "not writing XS" probably isn't a valid reason.
> So, on the assumption that having autodie in the core is a good thing, I
> would like to propose:
>
> * Variable::Magic be strongly considered for core inclusion. It only has
> core dependencies, and it works pretty close to Perl's guts.
>
> * B::Hooks::EndOfScope be considered for core inclusion. It's a tiny
> amount of code, but provides a very useful service for anyone wanting
> to write lexical pragmas or code. B::Hooks::EndOfScope may need to
> be tweaked to remove the CPAN dependency on Sub::Exporter.
I am not comfortable with this.
This is a late stage decision. It's inherently rushed. Rushed decisions are
rarely good.
Given that autodie is not *yet* in 5.10.0, I think it would be better to
defer introducing autodie until we have had time to think about this.
In particular:
1: The proposal is to bring in all of Variable::Magic, in order to use one
interface it provides. However, this inherently offers all of its interface
as part of the core distribution, which means that all of that interface
needs to remain. We can't hide the parts of the interface it does not need.
2: Modules in core control both ends of the XS interface.
Modules on CPAN can't.
Whilst the end result of a module on CPAN might be exactly what is desired
here, it's implementation may not. On CPAN, it's inherently constrained to
use the interface the core already exposes. It might be using it in
undocumented ways. So we might be
a: about to add something that is actually fragile in its implementation
b: about to "bless" that way of doing things, based on the copy-paste
"do as I do" model of how a lot of CPAN code actually ends up being
written
Please could we step back and work out what we're actually trying to do here.
> In a nutshell, autodie stuffs objects into %^H at compile time. When Perl
> reaches the end of the current lexical scope, anything in %^H turns into a
> string, triggering object destruction, and allowing me to undo the magic
> that autodie has inserted. It's the mechanism which allows autodie to have
> truly lexical scope.
>
> When a string eval is compiled under 5.10.x, it copies the contents of %^H,
> so that when the eval is executed, it can keep the same %^H contents as when
> it was being compiled. I understand this may be a feature (and may even be
> required for 'use feature' to work).
>
> Unfortunately, this also increases the ref-count of objects in %^H, which
> means that destruction doesn't happen when I expect it to happen. I can
> demonstrate this with an example:
>
> {
> use autodie;
> eval "1";
> }
>
> open(my $fh, '<', 'no_such_file');
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?
[because autodie needs to C<local>ise things like C<open> for the duration of
parsing the block?]
Nicholas Clark
Thread Previous
|
Thread Next