develooper Front page | perl.perl5.porters | Postings from August 2012

Re: fixing smartmatch just hard enough (and when, too)

Thread Previous | Thread Next
Jesse Luehrs
August 25, 2012 12:50
Re: fixing smartmatch just hard enough (and when, too)
Message ID:
On Sat, Aug 25, 2012 at 01:14:10PM -0400, David Golden wrote:
> On Sat, Aug 25, 2012 at 9:22 AM, Ricardo Signes
> <>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.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About