Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116790
MIME-Version: 1.0
References: <CAMrTa2Emxro81j7UMA5QZ+wCOY7g46LSotLRD4oUG7HEfqSD0A@mail.gmail.com>
 <CAF+90c82zZbz=uCcZ9EBXUa0XquWwvQ_572mipzpit4O0_vHCg@mail.gmail.com>
In-Reply-To: <CAF+90c82zZbz=uCcZ9EBXUa0XquWwvQ_572mipzpit4O0_vHCg@mail.gmail.com>
Date: Mon, 3 Jan 2022 18:27:19 +0000
Message-ID: <CA+p1FaakWmKp+ynv3z8xYjOQqKXUZDZqwYV=cqaahWRH2RtNUg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Jordan LeDoux <jordan.ledoux@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000bb05f605d4b1acea"
Subject: Re: [PHP-DEV] [VOTE] User Defined Operator Overloads
From: davidgebler@gmail.com (David Gebler)

--000000000000bb05f605d4b1acea
Content-Type: text/plain; charset="UTF-8"

On Mon, Jan 3, 2022 at 5:38 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Mon, Jan 3, 2022 at 1:14 AM Jordan LeDoux <jordan.ledoux@gmail.com>
> wrote:
>
> > Hello internals,
> >
> > I've opened voting on
> > https://wiki.php.net/rfc/user_defined_operator_overloads. The voting
> will
> > close on 2022-01-17.
> >
> > To review past discussions on this RFC and the feature in general, please
> > refer to:
> >
> > - https://externals.io/message/116611 | Current RFC discussion
> > - https://externals.io/message/115764 | Initial RFC discussion
> > - https://externals.io/message/115648 | Pre-RFC discussion and
> > fact-finding
> >
> > Jordan
> >
>
> Voted No on this one. I did support the previous proposal on this topic,
> but I don't like the changes that this iteration has introduced relative to
> the previous proposal.
>
> The part that I dislike most (and that I consider an exclusion criterion
> regardless of any other merits of the proposal) is the introduction of a
> new "operator +" style syntax. I found the motivation for this choice given
> in the RFC rather weak -- it seems to be a very speculative
> forward-compatibility argument, and I'm not sure it holds water even if we
> accept the premise.

There's nothing preventing us, from a technical
> point-of-view, from allowing the use of some keyword only with magic
> methods. On the other hand, the cost of this move is immediate: All tooling
> will have to deal with a new, special kind of method declaration.
>

I agree wholeheartedly with this. I don't have a vote but if I did I'd vote
no. I think if operator overloading is to be introduced, new magic methods
using names like __add and __equals are preferable for a number of reasons.


>
> I'm also not a fan of the OperandPosition approach, though I could probably
> live with it. The previous approach using static methods seemed more
> natural to me, especially when it comes to operators that do not typically
> commute (e.g. subtraction).
>
> Regards,
> Nikita
>

--000000000000bb05f605d4b1acea--