Front page | perl.perl5.porters |
Postings from September 2015
* Ricardo Signes <perl.p5p@rjbs.manxome.org> [2015-09-10 17:30]: > # STEP TWO > $obj ~~ $x --> uses ~~ overloading if present, otherwise pass > > The change here is "Step Two." I'm not particularly a fan of it, and > would discourage it This seems like a very bad idea. That single addition defenestrates the regularity of the entire ruleset, by reintroducing the possibility for the LHS to influence what type of check will be performed – which was only the biggest problem with the original symmetric smartmatch… That said, I think this could be acceptable, but for one thing: that it uses the same overload method for $x ~~ $obj as for $obj ~~ $x. I know we have a mechanism to signal which side of the expression an overloaded object was on, but I think in the case of this particular distinction it is arguable that these are completely separate operations. Therefore an ~~ RHS overload should not even be called if the object occurs on the LHS of a smartmatch and likewise, an ~~ LHS overload method should not be called at all if the object finds itself on the RHS of a smartmatch. Even in this form, I think this is likely to eventually come to be seen as a mistake, as Zefram said. But at least it could be limit the damage to “never use a ~~ LHS overload” becoming part of the folklore, instead of jeopardising the entire feature. > but it has the practical benefit of keeping autodie working. Compromising a core language feature to keep a library working seems like a really bad tradeoff at first glance. But if I understand the problem correctly, it’s not the code of autodie itself, it’s the interface that autodie has advertised so far, i.e. the cost we’re talking about isn’t patching autodie itself, it is patching all of the users of the autodie smartmatch interface. Is that correct? If so, then yeah that’s a pretty serious problem, and I can understand contemplating desperate measures like compromising the language design in favour of not having to impose that cost. Again, splitting the LHS vs RHS overloads might mitigate the compromising of the feature to an acceptable level. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>Thread Previous | Thread Next