Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115695
Message-ID: <9BCF1D9C-362A-40AF-9C7C-CC02B002BBD9@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_F2C27DF0-B167-40F1-A86F-83D8B259255C"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Date: Wed, 11 Aug 2021 12:53:07 -0400
In-Reply-To: <CAMrTa2H_B7EKizjxxfG9rMgF+tgG6HFwQce2wAWJ2UtaTgv14A@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
To: Jordan LeDoux <jordan.ledoux@gmail.com>
References: <CAMrTa2EO-5nyoCYkHhMVxQ4nucRoHJj0=M=W22kUaW0jpHkHLg@mail.gmail.com>
 <f01eed58-6ccb-91a9-16d0-0f0c4e97d98a@gmail.com>
 <CAMrTa2E-pV+xP+3NJ=zd0S7N2agVRGiALaaJCBUaM=UwETEArw@mail.gmail.com>
 <94696d46-c4e6-406a-b859-89144bff31bf@www.fastmail.com>
 <D4BCCF3A-2DA1-4091-917D-7EBDB4A1AB5C@newclarity.net>
 <CAMrTa2GLQuVAKL089ykDJnBfVw=MNP-3qiTzHFpjQ8WTmUK+Lw@mail.gmail.com>
 <C2BA0FDB-2E9D-43CF-B63A-CE3C39B6EFB3@newclarity.net>
 <CAMrTa2HP8Q56qvcmAXe6W69OsSNwTNeFjRrP304G=ARubRxkZw@mail.gmail.com>
 <FE49BA62-2CAE-4446-AE56-B231A23015D3@newclarity.net>
 <CAMrTa2FNWg4bMo7uS+d_tKPVx8WkeaWs=kOEPF-4zSC7mnA4Xw@mail.gmail.com>
 <F925C8A6-84EB-43F5-A4D7-ED5CF4A02040@newclarity.net>
 <e83810b6-2f34-450b-8715-587fb3f1d4b5@www.fastmail.com>
 <3D7F74C1-F1A0-4258-8EE3-3C143B6B54EB@newclarity.net>
 <CAMrTa2F_1qjhwUbN8WaeN83+H2hh+8AJt8QO4U3mpokZOjZaRw@mail.gmail.com>
 <E4EC36E4-6299-439A-A537-49BF79EFC559@newclarity.net>
 <CAMrTa2H_B7EKizjxxfG9rMgF+tgG6HFwQce2wAWJ2UtaTgv14A@mail.gmail.com>
Subject: Re: [PHP-DEV] Revisiting Userland Operator Overloads
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_F2C27DF0-B167-40F1-A86F-83D8B259255C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> On Aug 11, 2021, at 5:25 AM, Jordan LeDoux <jordan.ledoux@gmail.com> =
wrote:
>=20
> I want to avoid this. :) The implementations in my actual math =
libraries are much more thorough and thought out. This is an example. If =
people want to see something that is closer to what would actually be =
done in a library, they should look at an actual library. So instead, =
that's what I'll link to:
>=20
> Here's the multiply method: =
https://gist.github.com/JordanRL/98cceb392ba5ba943462fe574f18de51 =
<https://gist.github.com/JordanRL/98cceb392ba5ba943462fe574f18de51>
> Here's the translateToParts method: =
https://gist.github.com/JordanRL/2c67acb3b5d3069c3a4d2f0448a480d1 =
<https://gist.github.com/JordanRL/2c67acb3b5d3069c3a4d2f0448a480d1>
> Here's the PolynomailFunction: =
https://gist.github.com/JordanRL/673e357e7f5cf63bd4554fb3161c026b =
<https://gist.github.com/JordanRL/673e357e7f5cf63bd4554fb3161c026b>
>=20
> You can think of ImmutableDecimal as Real|Imaginary, but with methods =
such as $obj->isReal() and $obj->isImaginary() on it.
>=20
> This is just for the __mul() method. The intent of this example is to =
show the nature of the problems being solved, not to show the actual =
solutions. Think of this as syntactically correct pseudo-code, not an =
actual implementation.

Well, I refactored not to provide an actual implementation but to try to =
show the problems being solved in a manner that could be more easily =
understood. But it is your RFC, so it's yours to decide how code is =
presented.

----

Anyway, I'll summarize as I am going to try to wrap up my participation =
in this topic, at least for now:

1. I argue that it would likely be a mistake to add general purpose =
operator overloading to classes in PHP (or at least before a lot of =
experience with #2.)

2. However, I recognize there are use-cases which beg for operator =
overloads I think PHP. And I believe those use-cases are finite: money, =
the math examples, and units[1] being three (3) subsets.  I think PHP =
would be better served by adding those use-cases as standard library =
classes[2] instead of adding general purpose operator overloading to the =
language.

3. However, *if* there is strong consensus that we should add general =
purpose operator overloading then I argue that it should be limited to =
"value" objects, which currently would mean only classes where all =
public and protected properties are read-only[3].

4. And even if we do #3 that is no reason for us not to consider also =
doing (at least some of) #2.

#fwiw

-Mike



[1] https://www.nist.gov/pml/weights-and-measures/metric-si/si-units =
<https://www.nist.gov/pml/weights-and-measures/metric-si/si-units>

[2] I mean, how great would it be to have a Length class with unit =
conversions built into PHP?  Or a Money class that all libraries that =
deal with Money would be able to interoperate with? Having these =
non-changing concepts built-in to PHP would be a strong reason =
developers to choose PHP over other options like Node where they have to =
manage tons of ever-changing and incompatible 3rd party dependencies. =
Better that than 10+ different userland implementations of the same =
bedrock concepts, many of which are incomplete and all of which are =
incompatible with each other.

[3] Yes, private property values could be changed by methods and thus =
leak to the outside. But that could be considered an anti-pattern. If =
said private property(s) (partially) represent the state of the object =
and are not readonly then we could simply recognize that as an unchecked =
bad practice.


--Apple-Mail=_F2C27DF0-B167-40F1-A86F-83D8B259255C--