Front page | perl.perl5.porters |
Postings from August 2012
David Golden analysed: > what Damian described *except* that he suggests > making right side overloading take precedence over the left side. > > And to that -- why? Should it be completely consistent instead, where > overloading on the value being tested (left side) takes precedence over > overloading on the comparison value (right side)? > > Presumably, overloading on the value would be due to it replacing the object > with a different value to actually compare and would then smartmatch on the > replacement value against the original comparator -- which would then > trigger the overloading on the comparator and do the right thing. > > On the contrary, overloading on the comparator might result in a different, > non-smartmatch comparison being performed. That might trigger different > overloading on the value (e.g. "eq" or "=="), but would bypass smartmatch > overloading. That seems likely to lead to bugs by incautious overloaders. > > Removing special cases is *good*. Let's make smartmatch overloading work > just like other operators. The argument for the ordering I've proposed to prefer the RHS object's ~~-overloading is that every other (non-overloaded) case in the smartmatch table dispatches solely on the RHS type. So, for consistency and predictability of *use*, I believe overloaded ~~ should favour the RHS object's overloading (if any) and fallback to the LHS object's overloading only if necessary. In other words, I think it's more important to make overloaded-~~ as consistent as possible with the behaviour of non-overloaded-~~, than it is to make it consistent with the behaviour of other overloaded operators. The risk of error has to go somewhere: better it fall to the implementer of the overloading (who presumably knows how they want to make this particular sausage) than to the users of the overloading (who presumably don't want to have to know how their sausages are made). DamianThread Previous | Thread Next