Front page | perl.perl5.porters |
Postings from June 2008
Re: autodie.pm design questions
From: Paul Fenwick
June 3, 2008 15:40
Re: autodie.pm design questions
Message ID: 4845C389.firstname.lastname@example.org
Roland Giersig wrote:
> Isn't Fatal going to be deprecated and replaced by autodie?
To me, deprecated implies that we're going to withdraw support for it in the
future, in the same way that pseudohashes were deprecated. However
supporting Fatal isn't difficult; it's really easy. We don't want people to
*have* to remove it from their code.
There are a few things inside Fatal we're declaring as bugs, and that I've
removed. Most notable in here are 'no Fatal', and the AUTODIE behaviour
inside Fatal, both of which were discussed on p5p a few months back.
There's also a few things I'm improving, such as the error messages from
Fatal. This *may* actually break backwards compatibility for anyone
searching for particularly ugly strings in $@, although searching for simple
strings (eg, /open/) should still work fine.
I'm not sure if I should be worried about this or not.
> Keep Fatal for legacy reasons but strongly push
> autodie as the 'better Fatal'. This makes for a clean transition: old
> code can continue to use Fatal, new code should be written with autodie.
This I certainly agree with, new code is encouraged to use autodie, since it
doesn't result in action from a distance, and guarantees a nicer way of
> When refactoring code, either keep Fatal or completely switch to autodie.
The current implementation allows some mixing, provided that mixing is
essentially a no-op. So using 'autodie qw(open)' is just fine if 'Fatal
qw(open)' is in effect. It's an unambiguous no-op.
>> * What should a plain 'no autodie' mean?
> 'no autodie' in a local scope switches off all autodie behaviour from
> there to the end of scope.
It does indeed. ;) I had a neuronal misfiring, I meant to be asking what a
plain 'use autodie' should mean. One could consider it to be an error (you
have to ask for *something*, although that something could be ':all'). One
could consider it a no-op, since we didn't ask for anything (but I don't
like this, nobody would write "use autodie" if they expected it to do
nothing). The final option, which I think makes the most sense, is to
enable autodie for a default set of functions, which matches the behaviour
of other pragmas like strict and warnings.
The list of sensible defaults I think includes all the built-ins for which
we normally *should* check for failure if we weren't using autodie/Fatal.
Under a role-based system user-defined subs may also wish to add themselves
to this set, but I don't have a full mental map for registering user subs yet.
> Maybe system shouldn't autodie in the default "use autodie" case, only
> if the user specifically asks for it via "use autodie qw(system)" or
> "use autodie qw(:reallyall)"? If the user decides to shoot his own foot
> by using it with the special form of system() even though the docs
> clearly state "don't do this"...
I'd like this idea if we were breaking system() in a subtle way; but we're
not. We're breaking a particularly exotic form of system in an extremely
blatant way - we're making it a syntax error. If we break it, the code
Add to this is the fact that the exotic form is quite rare, and easy to fix
(just prefix it with CORE::) and I'd argue it's much better to include
system in autodie's default behaviour, and perhaps provide a switch to leave
it out. It's essentially huffman encoding the pragma for what I hope will
be the most common case.
> Dependencies meaning IPC::System::Simple and some exception-handling
> modules? IPC::System::Simple sounds like it could be useful for other
> things too...
Since ISS is one of my modules, I appreciate the flattery. ;)
Thanks very much for the feedback, it's hugely appreciated,
Paul Fenwick <email@example.com> | http://perltraining.com.au/
Director of Training | Ph: +61 3 9354 6001
Perl Training Australia | Fax: +61 3 9354 2681