Front page | perl.perl5.porters |
Postings from June 2008
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
backward-compatibility.
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),
Roland
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/Fatal.pm 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] http://search.cpan.org/perldoc?IPC::System::Simple
>
Thread Previous
|
Thread Next