Front page | perl.perl5.porters |
Postings from August 2012
Abigail observed:
> You know, for me the current proposals that lead up to this exception
> doesn't make me very happy.
Well, happily, the current proposal no longer has that exception. ;-)
> If I got to use ~~ plus additional syntax
> to force perl to use either == or eq comparison, I might as well use
> == and eq to begin with, and save typing.
Indeed. And in the cases where you know your exact type, that's
precisely what you should do. Smartmatching should be reserved for the
cases where you don't.
And frankly, it's a bad idea not to know what the LHS of a smartmatch is,
since that's where the polymorphic decision-making for the operator
actually occurs.
> On top of that, for years we have been buggering people on use of "$var"
> as being bad practise, and now we want a warning to promote it?
The warning doesn't have to promote it. The warning could say:
Ambiguous operand ($x) in smartmatch at example.pl line 7
(Did you need eq or == instead?)
> Besides, if someone were to use:
>
> $var ~~ $x;
>
> and $x could be a number or a regexp, but in one of the runs gets served
> the above warning (because this time, the code path has printed out $x),
> and changes it to:
>
> $var ~~ 0 + $x;
>
> it ain't going to work well in case $x is a regexp (or a coderef, or has
> overloaded ~~ but not +, or has overloaded +, or several other cases), is it?
You're right. That's a problem. That's *the* problem.
The correct long-term solution is for Perl to know what type a scalar
actually contains, and not to subsequently lose that knowledge merely
because of internal side-effects and optimizations of the implementation. :-(
I wish I had a good short-term solution as well, but I don't. We're
trying to add an essentially non-auto-coercive feature to an essentially
auto-coercive language, and the simple scalar as LHS is the single point
at which we get stuck between those two world-views.
Some would say that's reason enough to abandon smartmatching
(because it's intrinsically different from most of the other Perl 5 operators).
I would argue that's precisely why we need it: it's different because it
fills a gap...and a need. Perl 5 hasn't ever provided an easy way to
match polymorphically...and it should. Even if that way isn't perfect (yet).
Damian
Thread Previous
|
Thread Next