Front page | perl.perl5.porters |
Postings from July 2009
[ SUMMARY: Only C<use 5.012> may disable split assignment to @_. ]
[ METASUMMARY: Let's put this to bed. Surely there are bigger fish to fry. ]
Michael G Schwern <schwern@pobox.com> writes:
> Making it a compile-time error isn't compromise, its picking the lowest common
> denominator.
Compromise makes bad design. Synthesis can make good design. They're easy
to mistake for each other, because both involve listening and adapting.
Let's spell out the scenario of just changing split:
1. split in scalar context no longer assigns to @_.
the syntax of split does not change, only its semantics. <--- vital point
2. people write code in Perl 5.12 that depends on the new semantics
3. it's syntactically valid Perl 5.10, 5.8, 5.6.1, etc.
4. when fed to those older Perls, the code compiles, but runs incorrectly
5. users feel they've been unfairly played
6. they're right
Breaking upward _or_ downward compatibility *silently* without a damn good
reason is impolite. I like to be impolite only for good reason. ("I don't
believe in breaking small laws." -- The Rebel Set)
A story from the past: The ability to correctly read directories containing
files named '0' is the reason Larry approved a change making
while ($x = <*>)
to silently mean something new:
while (defined($x = <*>))
As a practical matter this change was only good, even though it was a silent
semantic change. I bring up this story to show a silent semantic change is
*not* always bad, and I get that. But the reasons why the <*> change was
safe do not apply here.
So:
If you really want scalar split to simply return a count and not assign to @_,
then I'm OK with that... *if* it is only under C<use 5.012>. Chairman Larry
has been known to err, but I agree that "all is fair if you predeclare."
When Perl 5.12 encounters scalar split and *not* under C<use 5.012>, it should
either do 5.10 does, or die. Those are the only two options that make sense
if you're trying to make a usable tool.
--
Chip Salzenberg
Thread Previous
|
Thread Next