There's more than one way to do things | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
One thing that will surprise people is that it contains no provision for numeric comparison, so by the numeric/string duality, numbers will be compared as strings. Yes, I agree that this is the biggest weakness of the suggested rules. The problem of surprise could be partially mitigated by emitting a warning when a numeric literal is used as the RHS of a smartmatch (or as a when-expression), but of course numbers coming in through variables would still silently use string comparison. As for there being no way to employ numeric comparison, in theory people could create a Num class that overloads ~~ and forces numeric comparison, but such a solution likely won't be worth it to users of smartmatch or given/when (since the whole point of those features is to make things simpler).
Not ideal, but also not necessarily a deal-breaker. Of course, I would love to be proved wrong regarding separate string/number dispatch not being possible to do safely in Perl... :)
All good points. I guess it's better to leave those rules out then. As for junction semantics, it occurred to me that the problems/warts of the existing Junction module(s) on CPAN would probably go away once ~~ like described above (but without the three "bonus" rules) is in core and those classes have been updated to overload it (rather than relying on hacks like overloading == for non-standard things. So, support for $topic ~~ any('foo', 'bar', qr/baz/) would then be provided by those modules and would not need to be hacked into the smartmatch operator itself. And if, at a later time, one of those junction modules makes it into core too, then all the better. In reply to Re^2: Bring back the smartmatch operator (but with sane semantics this time)!
by smls
|
|