Paul Fenwick wrote: > G'day Bruce, Bruce, Bruce, Bruce, p5p, and Bruce, > > I realise that I should have made reference to the earlier p5p threads > on the discussion. Unfortunately I'm wolfing down my vegemite on toast > right now, and have to leave in 3 minutes to teach a course, so this > mail is short (and doesn't have links to original posts). > > * 'autodie' is the agreed upon name, although Bruce's suggestion of > 'bitchin::builtins' was a close second. No problem with that. I concurr, changing the name is better. > * Fatal will more or less remain as it is, although there is some risk > of breakage since it will be throwing proper exception objects, which > stringify into much nicer looking error messages. Isn't Fatal going to be deprecated and replaced by autodie? I think this would be the right way: 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. When refactoring code, either keep Fatal or completely switch to autodie. > * Having Fatal and autodie interact in any way where you'd have to ask > what's happening is an error. If the previous point is aggreed upon, any mixing of Fatal and autodie is an error, no? > I'd still really love feedback on my thoughts posted in my design > questions e-mail[1], specifically: > > * What should a plain 'no autodie' mean? In global or local scope? With our without a previous 'use autodie'? I'd vote for a pragma-like behaviour, 'use' enables, 'no' disables the functionality. 'no autodie' in a local scope switches off all autodie behaviour from there to the end of scope. > * Should we say "damn exotic system for this package" and > allow autodie to fatalise system()? 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"... > * If this is a candidate for core, what do I do about > dependencies? Should I try to avoid them entirely? Dependencies meaning IPC::System::Simple and some exception-handling modules? IPC::System::Simple sounds like it could be useful for other things too... Prost! RolandThread Previous | Thread Next