Front page | perl.perl5.porters |
Postings from August 2012
On Fri, Aug 24, 2012 at 02:12:40PM +0200, Eirik Berg Hanssen wrote:
> 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?
Using a "looks like a number" check leads to silent and hard to detect
bugs. For instance,
given ($foo) {
when ("a") { ... }
when ("b") { ... }
when ("0") { ... }
default { ... }
}
If this checks for "looks like a number" and does something different, I
might end up getting "0.0e10" or something accepted by the 'when ("0")'
condition, when that's clearly not what I meant. This kind of unexpected
and hard to detect behavior is one of the main things we're trying to
get rid of with this new proposal.
I do agree that having it do different things based on the underlying
representation of the value of a variable on the right hand side at
runtime is not really great either. Maybe we really do need to only
allow strings/numbers on the rhs of a smartmatch if they are explicitly
disambiguated.
But that would break things like
sub all_matches {
my $self = shift;
my ($matcher) = @_;
return grep { $_ ~~ $matcher } $self->things;
}
I'm starting to think that only allowing string matching (as in the
initial proposal) is going to be the only sane option here/: It's not
like numeric matching would be all that much harder even with that form:
'$thing ~~ sub { $_[0] == 2 }' or 'when { $_ == 2 } { ... }'.
-doy
Thread Previous
|
Thread Next