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