Front page | perl.perl5.porters |
Postings from September 2016
On Mon, 5 Sep 2016 14:50:52 +0100 Zefram <zefram@fysh.org> wrote: > We should either fix it or kill it. Fixing it should take the form of > reducing the matching behaviour table to just a handful of rows, of > which the main one relies on ~~ overloading on the rhs. Tony's > branch mostly does this. However, I disagree with permitting > overloading on the lhs. That part of Tony's branch (which is also not > properly documented) should be ripped out. The type of matching to > perform should be determined entirely by the rhs, and any type of > matching that amounts to "ask the lhs whether it matches" is too > surprising and not useful enough to warrant being a built-in matching > rule. Yeah, I'm with this. I've always found the weird type dispatch of binary operators, any operator, to be a little awkward. It's sortof excuseable for cases like $x + $y because so many people expect that to work, but since we don't have true MD in perl, we have to implement that by an ordered question - can $x handle addition; failing that, can $y? It's not great but it's expected so we live with it. If we are allowing overloading of ~~ then I don't fancy having to explain (or debug) the behaviour of $x ~~ $y when both are classes that have overloading logic. -- Paul "LeoNerd" Evans leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/Thread Previous | Thread Next