Ricardo Signes wrote: > This seems like complete madness. (I know I am quoting your words out of context, but they sound funnier that way.) Do we really need smart match at all? The three advantages to smart match I’ve seen are: • Junctive operations: ~~ @foo • Accepting qr// or sub{} from the caller and using it on the rhs • when(3) which is nice and short. (I don’t consider ‘we need a generic way of asking whether two objects match’ to be valid, because ‘match’ on its own is meaningless.) The first one we’ve solved with Perl6::Junction. The second one I don’t feel comfortable with at all. It is a very specific use case. Wrapping qr//s in sub{} I would consider the correct approach. The problem with any interface that accepts qr//-or-sub{} is that classes implementing one type of overloading can’t add the other without potentially breaking things. So it makes module authors’ lives harder. I’m simply not convinced that this feature is a pressing need. We already have generic matchers. They are called subs. The third one actually has nothing to do with smart match at all. It’s a ‘when’ problem. If we really really don’t want to have to write when($_==3), then we could copy the precedent set by flipflop and split. if (1..2) means if ($.==1 .. $.==2) split ' ' is special $x = ' '; split $x does something different and implement two syntactic special cases: # literal numbers when(0) when(1) when(0xff) when(0b101110) when(023476) # literal strings when('foo') when("foo") when(q "foo") when(qq "foo") and *nothing* else. Everything else would be a boolean, including when($foo). Anything else is madness; it really is. Then we can just deprecate ~~. Those who say they want when(num(3)) can write sub num { $_ == $_[0] } instead of sub num { my $arg = shift; sub { $_[0] == $arg } } which I think is an improvement. But that doesn’t work with lexical $_, so let’s deprecate that, too. (And make when do a simple next, and make given respond to next.)Thread Previous | Thread Next