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

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

Thread Previous | Thread Next
From:
Ricardo Signes
Date:
August 25, 2012 16:02
Subject:
Re: fixing smartmatch just hard enough (and when, too)
Message ID:
20120825230248.GA1776@cancer.codesimply.com
* David Golden <dagolden@cpan.org> [2012-08-25T13:14:10]
> 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".

Yes.  That's how I've always thought about it:  it's =~ but moreso. :)

> That led me to an additional thought about why defaulting to string
> comparison in the ambiguous case makes sense:
> [...]
> 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.

Good, because I have favored that working-with-warning behavior for ambiguous
simple scalars.  (What about `$x ~~ $glob`?  That's where I liked
undef-and-warn.)

-- 
rjbs
Thread Previous | Thread Next

nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About