Front page | perl.perl5.porters |
Postings from August 2012
On Thu, Aug 23, 2012 at 1:48 AM, Damian Conway <damian@conway.org> wrote: >> So maybe what we really want is to move that case down below the "Any -> >> Code" case. > > I don't think so. If overloading is tested first, then the overloading > itself can implement > a fallback to the standard Any ~~ CodeRef case. > > If Any ~~ CodeRef is tested first, then new classes have no way to > intercept and > control that behaviour sensibly for their objects. > > In fact, I would argue that the overloading case should come *first* > in the table, > even before the Any ~~ undef case, so that classes overloading smartmatch can > intercept and handle that case too. I suspect in practice junctions may be the only use-case for it. I can't think of any other use-case. I don't think it's a good idea to special case, TBH. > So what if I want *correct* junctive behaviour in that case: namely that > each element of the junction is distributed over a separate call to the sub > and the results are rejunctified. Why do you expect that to work with smart-match when it doesn't with subroutine calls, or a dozen other things? > You're proposing that: > > any(9,10,11) ~~ \&is_prime > > be equivalent to: > > is_prime(any(9,10,11)) > > but what if I want it to mean what it's supposed to mean: > > any(is_prime(9), is_prime(10), is_prime(11)) If «is_prime(any(9,10,11))» is not equivalent to «any(is_prime(9), is_prime(10), is_prime(11))», it's not a junction in the first place. It's just an abstraction that fakes it half of the time and leaks like a sieve the other half. Supporting them in a few circumstances and not in others seems silly and wrong to me. IMO doing them half-arsed is worse than not doing them at all. > If overload testing comes first, I can implement the Junction class's > overloading to do that. If CodeRef testing comes first, I'm screwed. No you're not. If you solve the problem at the other end, it's possible to write a solution that would actually work. That will require an approach that is much less superficial than what you're approaching here though, sadly. LeonThread Previous | Thread Next