On Sun, Dec 12, 2021, at 2:55 AM, James Titcumb wrote:
> On Thu, 9 Dec 2021, 20:12 Jordan LeDoux, <jordan.ledoux@gmail.com> wrote:
>
>>
>> RFC Link: https://wiki.php.net/rfc/user_defined_operator_overloads
>
>
> I'm not strongly opinionated on either approach (magic __add vs operator +)
> although I have a very slight preference to your propose operator + syntax,
> however despite very occasionally thinking that this would be a useful
> feature, I always start to think about all the awful ways this could be
> used, making debugging and reasoning about code harder, since unexpected
> magic behaviour can (and probably will be) introduced.
>
> The proposal is technically reasonable, pending consideration of reflection
> and so on, but I just think the desire to use this in ways it shouldn't be
> used will be too great, and we'll end up with horrendous complexity.
> Perhaps I'm too cynical.
>
> The only mitigation for unnecessary complexity I can think of is to force
> overloaded operators to be "arrow functions" to encourage only minimal
> code, e.g.
>
> operator +(Number $other, OperandPosition $operandPos): Number => return
> new Number ($this->value + $other->value);
I don't think that would be possible. As many of the examples in the RFC show, there are
numerous cases where an operator function/callback/thing will need branching logic internally. Even
if we did that, people could just sub-call to a single function which would be just as complex as if
it were in the operator callback directly.
(Though I still would like to see "short functions" in the language, despite it having
been rejected once already.)
--Larry Garfield