# from Michael G Schwern
# on Monday 26 February 2007 05:53 pm:
>Put another way... be lax in what you accept, strict in what you
>output.
That's a different subject having more to do with piped text than code
(if anybody in this case is being strict about acceptance here, it's
perl) and even if it weren't, that philosophy can only go so far.
What we have here is more a case of walking on eggshells, doing various
preventative things "in case somebody ____'d." How many cases can you
account for? And, is it worth the loss of an idiom to try to sweep
this flaw under the rug?
>Also this:
> eval { delete $SIG{__DIE__}; $obj->isa($class) }
>is no shorter than this:
> eval { local $SIG{__DIE__}; $obj->isa($class) }
To be clear (since I must not be funny enough), the delete() bit was a
joke. This is much shorter than both:
eval {$obj->isa($class)}
>>Or you could always just walk down the hall and
>> tell whoever wrote it to fix it.
>That's a long bloody hall you've got there for CPAN code.
I would hope to not find many modules on CPAN that install such a thing.
It's global, so whoever wrote $0 gets to decide what to do with it.
That's a pretty short hall in most sane situations.
>And how do
>you know the user didn't intend it to run even if its in an eval?
The bit about it "might be fixed later" implies that this intention
would eventually lead to disappointment anyway.
>>But, it's very clear in both perlvar and
>> perlfunc#die, so why bother with the eval {local $SIG{__DIE__}; ...}
>> mess? Just cause broken code to break instead of working around it.
>
>BECAUSE WE ALL THROUGHLY STUDY THE DOCUMENTATION, RIGHT?!
>
>Yeah.
Thoroughly study? It apologizes about the brokenness (in both places)
before it even explains how to use it!
>People do it wrong because its easier to do it that way. And it
> usually works fine. Most people don't even know about $^S. Hell,
> even the designers didn't think of it as evidenced by the accidental
> feature.
>
>Doing it slightly wrong but usable is easier than doing it right.
>That's why nobody does it right. Design failure.
Sure it's a design failure. But, breaking broken code is easier than
accounting for ignorance with the unfortunate side-effect that the user
learns something. The ignorance goes away and balance is restored.
To be clear, I totally agree that it is a design failure. To cite a
seemingly completely unrelated issue: a buggy reimplementation of
require() that is a direct result of not understanding that a bad
$SIG{__DIE__} could be fixed to allow eval {require foo} (and possibly
not realizing that local $SIG{__DIE__} would be an option.) So, the
code in question digs around in @INC to see if it can find a file.
Unfortunately, that solution breaks @INC subrefs. So, now we're down
an idiom and a feature! If the perpetrator of the die hook in question
had just been told "too bad", that mess wouldn't have happened.
Yeah, it shouldn't suck that much and ruby should be faster and perl 6
should be out by now and python should just exit instead of suggesting
that maybe you meant Ctrl-D.
--Eric
--
The only thing that could save UNIX at this late date would be a new $30
shareware version that runs on an unexpanded Commodore 64.
--Don Lancaster (1991)
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
