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

Re: design questions

Thread Previous | Thread Next
Roland Giersig
June 2, 2008 08:40
Re: design questions
Message ID:
G'day Bruce,

I'm wondering, would it be feasible to retrofit Fatal so it also can 
work locally? This would mean to rename/alias autodie to Fatal and add 
some backward-compatibility sugar.

If you

  use Fatal;

in global scope, it should have global scope. But if you

  sub a_local_scope_and {
    use Fatal;

it could detect that it is used inside a local scope and thus act 
locally, giving a warning on the side telling that we broke 

Wouldn't the warning be a good thing generally? If Fatal is used in 
non-global scope, emit a warning that it should be moved to global 
scope. Or is this too much nagging?

Or you could

  use Fatal::Locally;

which would make all following scoped Fatals act locally.

I'm not opposing the autodie name, please see these suggestions as an 
addition and as a trial to rectify the somewhat broken semantics of Fatal.

Cheers and greetings from austria (the *other* australia),

Paul Fenwick wrote:
> G'day p5p,
> I'm playing with a few design ideas for autodie, and would love your 
> feedback.
> == Meaning of vanilla 'use autodie' ===
> Presently it's possible to:
>     use autodie qw(:all);
> and enable autodie (lexical fatal) for all the built-ins on which 
> autodie could normally be used.
> I'd like to float the idea that it should be possible to write:
>     use autodie;
> and have that mean the same as 'use autodie qw(:all)'.
> == system() ==
> The system() built-in can't normally be overridden cleanly, because it 
> doesn't have a prototype.  The reason there's no prototype is because 
> the exotic form:
>     system { $name } @args
> doesn't take kindly to prototyping.  However I'm going to suggest that 
> we ignore the fact that system can't be prototyped, and make it usable 
> with Fatal/autodie anyway.  I've already written a proof-of-concept, and 
> the side effects are:
>     * Code outside the current package isn't harmed.
>     * Code inside the current package will generate a syntax error
>       if the exotic form of system is used.
>     * The exotic system can still be used if CORE::system { $x } @args
>       is used instead.
>     * We can have system automatically throw a nicely formatted
>       exception if there's a problem.
> Any objections?  Should system() be included when asking for 'use 
> autodie qw(:all)', since it means the bare exotic system() is now a 
> syntax error?
> As for the definition of "system having a problem", I'm strongly 
> inclined to use the same rules as IPC::System::Simple[1], namely:
>     * Failing to start entirely (eg, command not found)
>     * Returning a non-zero exit value
>     * Being killed by a signal
>     * Being passed tainted data (in taint mode)
> == Dependencies ==
> I'd love for autodie/ to be a candidate for the core (albeit 
> probably dual-lifed), because I feel it has such widespread potential.
> While I'm very fond of low-dependency tools, I'd love to have the 
> opportunity to leverage Exception::Class (which in turn requires 
> Devel::StackTrack and Class::Data::Inheritable), and IPC::System::Simple 
> (which depends only on core modules) for exceptions and system() 
> processing respectively.
> Obviously we don't want a huge influx of modules into the core, so I'd 
> appreciate advice here.  autodie can exist without these modules, but it 
> will be reinventing the wheel, and potentially in a way that's not as good.
> Thanks in advance for the feedback,
>     Paul
> [1]

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About