On Sun, Dec 12, 2021, at 2:55 AM, James Titcumb wrote: > On Thu, 9 Dec 2021, 20:12 Jordan LeDoux, <jordan.led...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
