Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116809
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: Wed, 5 Jan 2022 13:50:40 +0700
Message-ID: <CAEZPtU4PPWnWecmpXfT4EO06TVD06J7=FgYQ0ZZ-DDdjMjiUpw@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: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [VOTE] User Defined Operator Overloads
From: pierre.php@gmail.com (Pierre Joye)

Hi Nikita,

On Tue, Jan 4, 2022 at 12:38 AM 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'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).

I hesitated too, however I think we can't escape this feature. Like it
was for the annotation, we need to find a compromise.

Your points are valid so I wonder if the RFC could be modified and get
to the point we could reach that compromise. There will be the
oppositions for the features as a whole, however I am optimistic about
our abilities to get there this time rather than wait yet again a few
years for something we know we will have anyway.

Best.
-- 
Pierre

@pierrejoye | http://www.libgd.org