Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116623
MIME-Version: 1.0
References: <CAMrTa2FB-EVGq29oLCU8fYkMYi+KsQiEAFv1xxMFO7vnm8e6=Q@mail.gmail.com>
In-Reply-To: <CAMrTa2FB-EVGq29oLCU8fYkMYi+KsQiEAFv1xxMFO7vnm8e6=Q@mail.gmail.com>
Reply-To: james@asgrim.com
Date: Sun, 12 Dec 2021 08:55:10 +0000
Message-ID: <CAOD_yv1VNMEDvkXNw74iNzUrfqV197eaTvif83Z0scsRU8j5Mg@mail.gmail.com>
To: Jordan LeDoux <jordan.ledoux@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b33f4505d2ef1d5b"
Subject: Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)
From: james@asgrim.com (James Titcumb)

--000000000000b33f4505d2ef1d5b
Content-Type: text/plain; charset="UTF-8"

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);

--000000000000b33f4505d2ef1d5b--