Front page | perl.perl5.porters |
Postings from August 2012
Re: fixing smartmatch (again (still))
Thread Previous
|
Thread Next
From:
Jesse Luehrs
Date:
August 28, 2012 12:42
Subject:
Re: fixing smartmatch (again (still))
Message ID:
20120828194205.GX11137@tozt.net
On Tue, Aug 28, 2012 at 02:43:48PM -0400, Ricardo Signes wrote:
>
> Let's try again.
>
> First, though, I want to say that I was really happy with the discussion about
> this. It was on topic, interesting, and helpful. Even if there *was* a holy
> ton of it!
>
> ## The New ~~ Operator
>
> $a $b Meaning
> ======= ======= ======================
> Any undef ! defined $a
> Any ~~-overloaded ~~ overloading is used
> Any Regexp, qr-ol $a =~ $b
> Any CodeRef, &{}-ol $b->($a)
> Any Any fatal
>
> So, this is the table I proposed in July 2011, and it's what I think we're back
> to. No special cases.
>
> There is no question of how ($x=5) somehow became ambiguous, because if $x
> contains 5 or "5" is is not allowed as the smartmatcher operator, period. Use
> Smart::Match and say stringwise(5) or numwise(5), or pass sub{$_==5}
>
> If both 'qr' and '&{}' are overloaded, '~~' must be overloaded to disambiguate.
>
> Switches are still okay.
>
> ## The new behavior of given/when
>
> given ($x) {
> when ($y) { ... } # $x ~~ $y
> when (4) { ... } # $x == 4
> when ('4') { ... } # $x eq 4
> }
>
> Deferred/computed values of any sort mean smart match.
>
> Two dead-simple special cases: Numeric literals mean ==. String literals mean
> eq.
>
> If you want one case for $x eq a or b or c, then:
>
> given ($x) {
> when (stringwise any qw(a b c)) { ... }
> }
>
> ## What about what Father C. said?
>
> Sprout proposed that smartmarch be jettisoned and that `when` always evaluate
> its parameter as a boolean expression, save for the same simple cases above.
>
> For the "$x eq a or b or c" example, that gives us at least two simple choices:
>
> given ($x) {
> # Here, "any" returns a "junction" that distributes the eq
> when ($_ eq any qw(a b c)) { ... }
> }
>
> Or:
>
> given ($x) {
> # Here, stringwise implies the "$_ eq"
> when (stringwise any qw(a b c)) { ... }
> }
>
> My thoughts on this are:
>
> • I like the idea that we can have matcher objects that can be passed in
> more succinctly than a sub. ->set_matcher(qr/../) or ->set_matcher($obj)
> both seems simpler to me than ->set_matcher(sub { /.../ }) or
> ->set_matcher(sub { $obj->match($_) })
>
> • If we do, then Smart::Match and many other things keep working as they have
> without needing to be rewritten. This is nice.
>
> As Father Chrysostomos suggests, perl does not *need* smartmatch. Really, it
> doesn't need need features. My question is, does perl benefit more from this
> fix to smartmatching than it does from simply removing it? I believe it does.
As far as I can tell, this resolves all of the (few) misgivings I had
about the previous version of the proposal. I would be very happy to see
this happen.
-doy
Thread Previous
|
Thread Next