Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116625
User-Agent: Cyrus-JMAP/3.5.0-alpha0-4514-g2bdc19e04f-fm-20211209.002-g2bdc19e0
Mime-Version: 1.0
Message-ID: <4032cbcf-a1a5-4e16-8563-cb24f7abcf17@www.fastmail.com>
In-Reply-To: 
 <CAOD_yv1VNMEDvkXNw74iNzUrfqV197eaTvif83Z0scsRU8j5Mg@mail.gmail.com>
References: 
 <CAMrTa2FB-EVGq29oLCU8fYkMYi+KsQiEAFv1xxMFO7vnm8e6=Q@mail.gmail.com>
 <CAOD_yv1VNMEDvkXNw74iNzUrfqV197eaTvif83Z0scsRU8j5Mg@mail.gmail.com>
Date: Sun, 12 Dec 2021 11:32:14 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)
From: larry@garfieldtech.com ("Larry Garfield")

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