Front page | perl.perl5.porters |
Postings from August 2012
On Sat, Aug 25, 2012 at 01:14:10PM -0400, David Golden wrote: > On Sat, Aug 25, 2012 at 9:22 AM, Ricardo Signes > <perl.p5p@rjbs.manxome.org>wrote: > > > > > Again: I really think the test-writer (that is, the programmer chosing the > > matching (not matched) operand) needs to be in control of the behavior of > > the > > test. > > > > Maybe we're thinking about smartmatch all wrong. It's really more akin to > the binding operator "=~" than it is to the comparison operators "==" and > "eq". (Albeit with lower precedence and is non-associative), and of > course, we don't allow overloading of "=~". > > Ignoring the s/// and tr/// cases and m// syntax games, these are > equivalent: > > $lhs =~ qr/.../; > $lhs ~~ qr/.../; > > Thinking about it that way, it's more apparent why the LHS shoudn't > overload the operator, and why we leave string/number interpretation up to > the RHS. > > That led me to an additional thought about why defaulting to string > comparison in the ambiguous case makes sense: > > * All numbers can be treated as string, but not all strings can be treated > as numbers. > > Thus, without an explicit cast, treating $lhs ~~ $scalar as $lhs eq $scalar > is non-lossy, whereas numeric comparison could be. I'm still fine with the > ambiguous case *warning*, but I think it should do something useful rather > than return undef and I think the string case is the most natural one to > use. > > Having undef as a return, while nice in the simple case, actually makes > things like junctions much messier because of the trinary logic. I think > we're on safer ground if we can stick with true/false. Again, +1. -doyThread Previous | Thread Next