Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117694
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
In-Reply-To: <CAMrTa2FhEkhpDAyPR=6tt1M=F7SZRhh9RYydSO7p_Xv80X=Dfw@mail.gmail.com>
Date: Sat, 7 May 2022 18:08:07 -0400
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <228027D9-954D-4CEE-9152-8A776E83B833@gmail.com>
References: <CAMrTa2FhEkhpDAyPR=6tt1M=F7SZRhh9RYydSO7p_Xv80X=Dfw@mail.gmail.com>
To: Jordan LeDoux <jordan.ledoux@gmail.com>
Subject: Re: [PHP-DEV] The future of objects and operators
From: mike@newclarity.net (MKS Archive)


> On May 6, 2022, at 6:16 PM, Jordan LeDoux <jordan.ledoux@gmail.com> =
wrote:
>=20
> Hello all,
>=20
> I took a while away after my operator overload RFC was declined. I've =
been
> mulling for the last few months how to move forward while respecting =
the
> concerns and feedback of those who abstained and those who voted =
against.
> But I feel like a separate discussion needs to happen first after
> considering many different approaches.
>=20
> # There is Considerable Demand For Improved Control of Operators with
> Objects
>=20
> This doesn't apply to all operators. I have not seen any comments in =
the
> last few months of digging of people who are desperate for the pow =
operator
> ( ** ) for instance. However, many people who work with math in PHP =
have
> use for at least the arithmetic operators and I see this comment =
frequently.
>=20
> Totally separate from the math domain, I've seen many comments about =
the
> desire to control the comparison operators: >, >=3D, =3D=3D, <=3D, <, =
!=3D, <>. This
> is something that would have numerous applications outside of =
mathematics,
> and there's even been an RFC worked on (that was declined in 2018) by =
Rudi
> to implement just comparisons.
>=20
> # Different Voters Have Different Concerns
>=20
> This is an issue that almost all RFC authors must deal with of course, =
but
> this particular subject suffers from it more severely than most. For
> instance, in some of the past proposals that were more limited than =
mine,
> there were comments that a full operator overloading solution should =
be
> provided instead of something halfway.
>=20
> However one of the comments I received more than once was that I =
should
> separate out the comparison operators into its own RFC, since those =
have
> applications outside the math domain.
>=20
> # Is Math A Valid Use Case?
>=20
> One of the more shocking (to me personally) pieces of feedback that I
> received from more than one person is that math is not a valid use =
case in
> PHP. I am... unsure about what to think of this opinion. I guess I =
would
> like to discuss and find out if this is widely believed among voters.

I will repeat what I suggested back before the RFC was voted on, and =
that is you consider *starting* your campaign for operator overloads =
with an RFC to add a built-in Math class (or set of classes) to PHP, =
one(s) that can have all the operator overloading it/they need(s).

Minimally the design process in the open would be insightful for =
everyone interested in the topic even if the RFC did not get accepted =
=E2=80=94 although the intent should be that it would =E2=80=94 because =
it would change the operator overload discussion from a very abstract =
one to a very concrete one.=20

It could also illustrate the benefit for operator overloading, and =
illustrate the design process of deciding on how operators are =
overloaded and what the benefits and tradeoffs are of different choices.

If the RFC did not pass, at least it could result in an understanding of =
which operators minimally need to be overloaded for the Math use-case =
and serve as a blueprint for adding Math objects in userland if and when =
sufficient general-purpose operator overloading could get added to PHP.

Further, if an RFC to add a built-in Math object to PHP passed it would =
effectively eliminate the red-herring of "I don't do heavy math work."  =
Such an RFC would also, of course, not have the other two (2) categories =
of objections that you named in your other email.

Again, #jmtcw

-Mike