develooper Front page | perl.perl5.porters | Postings from August 2012

Re: fixing smartmatch just hard enough (and when, too)

Thread Previous | Thread Next
From:
Abigail
Date:
August 24, 2012 04:17
Subject:
Re: fixing smartmatch just hard enough (and when, too)
Message ID:
20120824112016.GA22526@almanda
On Fri, Aug 24, 2012 at 09:02:40AM +1000, Damian Conway wrote:
> Michael Peters responded:
> 
> > What good explanation would exist for why my code would now (not just fail
> > to match) but fatally die?
> 
> Because the original $foo ~~ $x was (potentially) ambiguous.
> Perl doesn't (yet?) properly distinguish between numbers and strings internally,
> so smartmatch can't always tell what kind of data you're giving it.
> 
> 
> > How would you teach that?
> 
> The theory was that the exception itself would teach it:
> 
>     Ambiguous operand ($x) in smartmatch at example.pl line 7
>     (Did you mean "$x" or 0+$x?)


You know, for me the current proposals that lead up to this exception 
doesn't make me very happy. 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.

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?

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?



Abigail

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About