Front page | perl.perl5.porters |
Postings from August 2012
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.
-- David
--
*David Golden* <dagolden@cpan.org>
*Take back your inbox!* → http://www.bunchmail.com/
Twitter/IRC: @xdg
Thread Previous
|
Thread Next