develooper Front page | perl.perl5.porters | Postings from June 2008

Re: autodie.pm design questions

Thread Previous | Thread Next
From:
Paul Fenwick
Date:
June 3, 2008 15:40
Subject:
Re: autodie.pm design questions
Message ID:
4845C389.4050901@perltraining.com.au
G'day Roland,

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 
handling exceptions.

 > 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 
won't compile.

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

-- 
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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About