develooper Front page | perl.perl5.porters | Postings from September 2015

Re: smartmatch needs your eyes

Thread Previous | Thread Next
Aristotle Pagaltzis
September 11, 2015 22:04
Re: smartmatch needs your eyes
Message ID:
* Ricardo Signes <> [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.

Aristotle Pagaltzis // <>

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About