Dual-life and autodie (Pumpking input appreciated)
Paul Fenwick
autodie (a lexical flavour of Fatal) works. It works in 5.10, it works in
5.8, it may even work in 5.6 with a few tweaks. I've got some work to do
around the edges, but I'm now giving serious thought about moving towards a
*real* release (as opposed to a developer release[1]).
autodie is essentially a massive patch on top of Fatal. This means it can
interact with Fatal in a sane fashion. This is good.
However Fatal is a core module, and core modules can be hard to change,
especially if they're being applied to an existing version of Perl. This is
bad.
So, I need advice. I have two choices, and I need to know which one to take:
1) I've been assuming that the new autodie/Fatal is a candidate for
inclusion into the core, mainly because nobody has objected to the idea. If
this is the case, I can keep my existing architecture, and try to figure out
what to do when autodie gets installed form the CPAN[2]. This is relatively
easy, and results in a system which works nicely.
2) The other alternative is to turn autodie from being a massive patch into
being a massive hack. When autodie is loaded, it can find Fatal and
dynamically replace its guts with new code. I don't like this alternative,
because there's a whole lot of race conditions (like someone using Fatal
before autodie), and I don't have good solutions for these. It's painful,
but it completely avoids overwriting Fatal.pm.
Because I've been mindful of the inclusion of autodie in core, I've kept the
dependencies slim. The only true dependency is Scope::Guard, which I can
inline in a few lines. autodie also uses IPC::System::Simple (which has no
dependencies) to help implement the autodying form of system(). autodie
still works fine by itself, but it's a compile-time error to 'use autodie
qw(system)' without it.
I guess I can keep my current architecture without autodie entering the
core, although I'll still need to seek some sort of official blessings to
overwrite Fatal.pm (otherwise it ends up being an "unauthorised release" on
the CPAN).
Many thanks,
Paul
[1] You can grab the developer releases from the CPAN.
http://search.cpan.org/perldoc?autodie or track the development at
http://github.com/pfenwick/autodie
[2] I assume that dual-life modules are a solved problem, and that I can
use/borrow/steal code that arranges for modules installed from the CPAN to
replace the core code.
[3] A third alternative is for me to ignore Fatal altogether, but then any
interaction between Fatal and autodie is almost guaranteed to cause pain and
misery.
--
Paul Fenwick <p...@perltraining.com.au> | http://perltraining.com.au/
Director of Training | Ph: +61 3 9354 6001
Perl Training Australia | Fax: +61 3 9354 2681
Paul Fenwick
I've received a huge amount of feedback on autodie (a much improved lexical
version of Fatal) from various sources during the time that I've been
working on it. I'm extremely grateful for that feedback, and I've
incorporated many of the suggestions into the current version of the code.
I've had a number of people tell me how much they're looking forward to
using autodie in their own projects.
Unfortunately, I'm still unsure as to whether autodie will/should be going
into the core, and whether I should be trying to get my code out of
Fatal.pm. Splitting autodie from Fatal would mean the two won't play
together nicely, which is something I'd like to avoid.
Since autodie is working, and I'm just just tidying things up around the
edges, I'm assuming all of the following:
* Everyone loves the idea of me having mucked about in the guts of Fatal.
They love this because I've fixed some bugs, the public interface works the
same, and it plays nicely with autodie.
* Everyone loves me going to whatever work is needed to stop Fatal.pm
showing up as an "unauthorised release" on the CPAN, so I can release real
versions, which people can install using the cpan shell.
* Everyone loves autodie having no dependencies.
* Everyone loves autodie, except for the name. That's fine, because you can
subclass autodie and give it a new name.
* Nobody cares about autodie going in the core for 5.8.9 or 5.10.1, although
since it's tremendously better than Fatal, it would be nice if it did.
If I'm wrong about any of the above points, now's the time to let me know. ;)
Cheerio,
Paul
Aristotle Pagaltzis
> Nobody cares about autodie going in the core for 5.8.9 or
> 5.10.1, although since it's tremendously better than Fatal,
> it would be nice if it did.
I care, but I’m also I’m in no position to decide, so I’m not
sure knowing I care helps you in any way.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
Paul Fenwick
be found at:
As well as other locations where my blog is syndicated (including use.perl).
The latest dev release, codenamed "Aristotle" (in thanks for his help with
interface design) is featured, including a worked example on how to subclass
autodie to provide your very own "lethal" pragma (for those who liked the
name), and an example of using localisation to make Australian-friendly errors.
Paul Fenwick
Aristotle Pagaltzis wrote:
> I care, but I’m also I’m in no position to decide, so I’m not
> sure knowing I care helps you in any way.
It makes me feel warm and fuzzy inside. ;)
At this time, as long as nobody jumps up and down about me having altered
the guts of Fatal[1], inclusion in the core (or lack thereof) *shouldn't*
change any of my progress or design. I've only got core dependencies in
both the code and the tests, so being able to drop the whole thing into the
core *should* be relatively simple (says the developer who's never done this
before).
Presently I'm looking to ping mod...@perl.org to see how to remove the
'unauthorized release' flag from my CPAN uploads.
Cheerio,
Paul
[1] The public interface to Fatal still works *exactly* the same way,
including the stomach-churning error messages, and the context-splattering bugs.
Steffen Mueller
Paul Fenwick wrote:
> Presently I'm looking to ping mod...@perl.org to see how to remove the
> 'unauthorized release' flag from my CPAN uploads.
[...]
> [1] The public interface to Fatal still works *exactly* the same way,
> including the stomach-churning error messages, and the
> context-splattering bugs.
I'll just answer to both lists. mod...@perl.org can transfer ownership
and give co-maintenance permissions. That's what you'd need to get rid
of the unauthorized-release tag. However, since Fatal is in core, we
would need the permissions from the pumpking first.
Best regards,
Steffen
P.S.: I'll be away for a week starting Saturday, so I can't just monitor
p5p for an okay from Rafael unless it's today.
Abigail
>
> * Nobody cares about autodie going in the core for 5.8.9 or 5.10.1,
> although since it's tremendously better than Fatal, it would be nice if
> it did.
Executive summary: I don't know.
Long rambling:
1) It's not my decision.
2) I don't have any compelling arguments either way.
3) But if I were to decide, and only my opinion counted, I would only put
things in the core that are either thightly coupled with the internals
(and hence may need major work if the internals change), are required
to build/test/install Perl, or are required to bootstrap fetching modules
from CPAN. Of course, then the modules currently in "core" would be quite
smaller. ;-)
4) I haven't looked how autodie is implemented, so I don't even know whether
it would fit my own criteria for inclusion in the alternate reality where
I am the perl release dictator.
Abigail
Aristotle Pagaltzis
> will/should be going into the core, and whether I should be
> trying to get my code out of Fatal.pm.
How about we do it this way? Fatal gets dual-lifed and you get
a co- or primary maint bit for its CPAN rendition. Then autodie
becomes the new version of Fatal. That changes the question from
“should autodie go in core” to “do people agree to dual-life
Fatal under the auspices of PJF?” That question seems more likely
to get answered in the affirmative.
Paul Fenwick
Responding to a couple of mails at once to conserve precious electrons.
Aristotle Pagaltzis wrote:
> * Paul Fenwick <p...@perltraining.com.au> [2008-07-04 04:55]:
> That changes the question from
> “should autodie go in core” to “do people agree to dual-life
> Fatal under the auspices of PJF?” That question seems more likely
> to get answered in the affirmative.
Thank-you again, Aristotle. ;) Yes, this is indeed a better question, and
which can be answered independently to whether or not anything should be
going into core.
Abigail wrote:
> 4) I haven't looked how autodie is implemented, so I don't even know whether
> it would fit my own criteria for inclusion in the alternate reality where
> I am the perl release dictator.
Neither Fatal nor autodie are tightly coupled to the internals of Perl; the
only real dependency is on the behaviour of %^H in 5.8 and 5.10. Using the
Abigail test, there's no reason for either of them to be in the core.
Having said that, Fatal already is in the core, so people are going to
expect it to remain there. Autodie is implemented on top of Fatal (they
share the same guts) and is tightly bound to Fatal.
My argument for putting autodie into the core is that in almost every
circumstance where people are currently using Fatal, autodie would be a
better choice. There's no action from a distance (it's lexically scoped,
not packaged scoped), there are better error messages (Fatal's errors are
*way* too ugly), it throws real exception objects (which stringify to nice
messages), and it's easy to subclass to your needs (if you want to do
localisation, or use a different exception system, or just add your own
error handlers).
It's much easier to encourage people to do things a better way if they're
included in the core. ;)
Aristotle Pagaltzis
> It's much easier to encourage people to do things a better way
> if they're included in the core. ;)
That’s exactly the point in contention, though… today’s better
way is tomorrow’s worse one. Cf. CGI.pm.
Regards,
--
Aristotle | “Fools ignore complexity. Pragmatists suffer it.
Some can avoid it. Geniuses remove it.”
– Alan J. Perlis, _Epigrams on Programming_
Rafael Garcia-Suarez
> Abigail wrote:
>
>> 4) I haven't looked how autodie is implemented, so I don't even know
>> whether
>> it would fit my own criteria for inclusion in the alternate reality
>> where
>> I am the perl release dictator.
>
> Neither Fatal nor autodie are tightly coupled to the internals of Perl; the
> only real dependency is on the behaviour of %^H in 5.8 and 5.10. Using the
> Abigail test, there's no reason for either of them to be in the core.
>
> Having said that, Fatal already is in the core, so people are going to
> expect it to remain there. Autodie is implemented on top of Fatal (they
> share the same guts) and is tightly bound to Fatal.
>
> My argument for putting autodie into the core is that in almost every
> circumstance where people are currently using Fatal, autodie would be a
> better choice. There's no action from a distance (it's lexically scoped,
> not packaged scoped), there are better error messages (Fatal's errors are
> *way* too ugly), it throws real exception objects (which stringify to nice
> messages), and it's easy to subclass to your needs (if you want to do
> localisation, or use a different exception system, or just add your own
> error handlers).
I tend to agree with those reasons (and I don't like the current coreish
Fatal.) So yes, I'll apply a patch to add autodie to the core. Please send one.
(Sorry for responding that late, by the way.)
Paul Fenwick
Rafael Garcia-Suarez wrote:
> I tend to agree with those reasons (and I don't like the current coreish
> Fatal.) So yes, I'll apply a patch to add autodie to the core. Please send one.
> (Sorry for responding that late, by the way.)
Aye aye, Cap'n! Expect a big patch in the next couple of days after I've
done a bit of tidy-up, as well as making sure I have a sustainable system
for merging my repository across into the core directories.
No problems at all on the late response; given your recent happy
circumstances, I very much understand! ;)