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

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

Thread Previous | Thread Next
From:
Eirik Berg Hanssen
Date:
August 24, 2012 05:12
Subject:
Re: fixing smartmatch just hard enough (and when, too)
Message ID:
CAHAeAG4EnCKUctQLWnXoHTynuseJn9-g+KNs4u0fqKqmyJic7g@mail.gmail.com
On Fri, Aug 24, 2012 at 1:20 PM, Abigail <abigail@abigail.be> wrote:

> 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?
>

  Thank you.  I knew there was something about this Num vs Str that bugged
me, but I could not put my finger on it.

  Still not quite hard enough, this fixing.  Still a misfeature in my book.

  ... remind me, why was the looks_like_num-treat-like-num dropped?

  Say we have an object that overloads qr//, 0+, and "".  The current
proposal would prefer the qr//.

  Say we have an object that overloads 0+ and "".  The current proposal
would refuse to state a preference, instead smartmatching "as a Num only if
it is unambiguously numeric".

  What was the reason it should not prefer Num (whether overloaded or
looks_like_num) to Str, the same way it prefers qr// to either?


Eirik

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