Front page | perl.perl5.porters |
Postings from August 2012
On Fri, Aug 24, 2012 at 2:32 PM, Jesse Luehrs <doy@tozt.net> wrote:
> 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.
>
If that's not what you meant, why did you write that?
Why not SWYM:
given ($foo) {
when ("a") { ... }
when ("b") { ... }
when { $_ eq "0" } { ... }
default { ... }
}
If smart matching checks if some value (like an object) can be used as
a regex (or coderef), and if so, is matched against as a regex (or
coderef), even though it also has a string representation, why not also
check if it can be used as a number?
Only because use of overload::constant to create objects with overloading
other than num, string, boolean and arithmetic is not very common? Or
because they are SEP? (In the presence of such, C<< when ("a") >> may end
up matching against ~~-ol, &{}-ol, or qr//-ol, so it is could still lead to
silently and hard-to-detect bugs.)
> 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 } { ... }'.
>
That would still be sane, but it would mean Abigail's case of C<< when
($x) >>, where $x could be either a regex or a number, still could not be
handled by smart matching:
For regexen, C<< when { $_ == $x } >> will fail as bad as C<< when ( 0+$x
) >>.
Sacrificing smartness and ambiguity for the numerical case, but retaining
both for the coderef, regex, and string cases ...
Eirik
Thread Previous
|
Thread Next