Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116795
MIME-Version: 1.0
References: <CAMrTa2Emxro81j7UMA5QZ+wCOY7g46LSotLRD4oUG7HEfqSD0A@mail.gmail.com>
 <CADyq6sKP6fztfF54e_VTHJRMcB8b0_TahMTTY0hw8LAgciY61w@mail.gmail.com>
 <CAB-BujZB31Ccw6nhN9PG1-VDqt8YkijsYUBYPxJ-Ss1Ng4KJ+w@mail.gmail.com>
 <CADyq6sLh+e74qeMrOuX1_PdN40Jw7m=3wMGMmdF-rwXkJLS1mg@mail.gmail.com>
 <3225c921-9b26-d2e0-f76f-45fff6f5a12a@processus.org> <e0358c86-622e-4347-a36c-2e8e16759004@www.fastmail.com>
 <40a1e5fa-396d-d9ef-93ab-6fcfb5054092@processus.org>
In-Reply-To: <40a1e5fa-396d-d9ef-93ab-6fcfb5054092@processus.org>
Date: Mon, 3 Jan 2022 13:14:56 -0800
Message-ID: <CAMrTa2FCGwkJ+kOHbyh4e=jWOBaDtb8iJiUDjqSEpA-Yts7Cpg@mail.gmail.com>
To: Pierre <pierre-php@processus.org>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e7f17405d4b4031b"
Subject: Re: [PHP-DEV] [VOTE] User Defined Operator Overloads
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--000000000000e7f17405d4b4031b
Content-Type: text/plain; charset="UTF-8"

On Mon, Jan 3, 2022 at 9:07 AM Pierre <pierre-php@processus.org> wrote:

> I forgot to answer to that, specifically. I'd much more prefer to have
> an explicit `equals(object $other): bool` (magic or not, really I do not
> care) single method for equality only, that'd be great. In that sense, I
> much preferred specific RFC about `__equalsTo()` or `__compareTo()`
> alone that a huge generic operator overload RFC. I think both could
> actually be separated, it wouldn't be that weird.
>

Based on the feedback so far, I am... concerned that doing so would leave
the mathematical improvements out in the cold. It seems that a non-trivial
number of voters do not see mathematics as a desirable use case on its own.

There's not really anything preventing that part from being ripped out on
its own, but the mathematical overloads add almost no complexity on their
own to the patch. One of my main goals in contributing to PHP is to improve
its usability and performance in mathematics.

Using magic methods instead of the operator syntax would take perhaps 2
hours to implement, it's a fairly trivial change in the scope of the RFC.
However, I have no plans to bring this back in time for 8.2 should it be
declined with a magic method implementation. Fundamentally, there are many
voters that seem to be more concerned about possible abuse that empirically
does not exist in most languages which have this feature, instead of
improvements to one of the most neglected domains PHP is used in.

And that's the real crux: *most* (but not all) of the objections raised so
far suggest a future that factually does not exist in the example languages
we can look at which already have this feature. C++ is perhaps the one real
example of widespread abuse, however there are *multiple* aspects of this
RFC which *specifically* target and discourage that kind of abuse.
(Explicit typing of parameters, non-optional support for implied operators,
restrictions on the return types of the == and <=> operators, errors and
exceptions being propagated immediately, etc.)

Further, the operand is not passed by-reference in this implementation,
which flatly excludes many of the worst possible abuses.

I understand all of these objections, but I do not agree with them.
Obviously. If I did, then I wouldn't bring this RFC to a vote. What I have
proposed is the most restricted version of operator overloads in any
language I researched, and that is still not enough for many voters, some
of whom have flatly stated that there is no version of this feature they
would ever vote for. If that is the kind of headwind against quite
fundamental improvements to mathematics within the language, then all of my
energy will be required to produce any improvement at all, and I cannot
spend effort on things which are unrelated.

Jordan

--000000000000e7f17405d4b4031b--