Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116799
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> <CAMrTa2FCGwkJ+kOHbyh4e=jWOBaDtb8iJiUDjqSEpA-Yts7Cpg@mail.gmail.com>
 <CAB-BujZtUnesM_cWBS1T0R4=WA5MBjq6aUsXaEB5n99Pwq2wVQ@mail.gmail.com> <CAMrTa2GKG_c_dCt6urpAY4S=pSWKaMBCAZCC6CCu8A2b+FdXwA@mail.gmail.com>
In-Reply-To: <CAMrTa2GKG_c_dCt6urpAY4S=pSWKaMBCAZCC6CCu8A2b+FdXwA@mail.gmail.com>
Date: Tue, 4 Jan 2022 04:05:49 +0100
Message-ID: <CAB-Bujb_EuGeL7paigAggHxgKzCoKO_Z2d65bhYNM75-d_uhTA@mail.gmail.com>
To: Jordan LeDoux <jordan.ledoux@gmail.com>
Cc: Pierre <pierre-php@processus.org>, Larry Garfield <larry@garfieldtech.com>, 
	php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE] User Defined Operator Overloads
From: andreas@dqxtech.net (Andreas Hennings)

On Tue, 4 Jan 2022 at 03:23, Jordan LeDoux <jordan.ledoux@gmail.com> wrote:
>
>
>
> On Mon, Jan 3, 2022 at 4:05 PM Andreas Hennings <andreas@dqxtech.net> wro=
te:
>>
>> To me it is not surprising that an RFC like this would be controversial.
>> We could enter a wonderful new era of value objects with operators,
>> but it is hard to envision that beforehand.
>>
>> The best might be to find and advertise with use cases and examples
>> from other languages.
>> (as mentioned, I don't really know where to start looking, otherwise I
>> would have already shared something)
>
>
> Oh, this was always going to be a controversial RFC. :) Operator overload=
ing is controversial in most languages, even the ones that have it and don'=
t really have problems because of it. It's the kind of feature that doesn't=
 affect most people most of the time, but that all developers end up having=
 a strong opinion about one way or another. I talked about that a little bi=
t in the internals podcast episode I did with Derick.
>
> NumPy is probably the absolute best example of this feature being used. N=
umPy is an absolute killer feature of Python, and drives an enormous amount=
 of the development being done in the language. It could easily be pointed =
out that NumPy is the equivalent of an extension however, being compiled do=
wn and directly hooking into the Python language. NumPy is also not include=
d in the core Python language, though operator overloading *is*, importantl=
y. However, the toolchain for adding NumPy is much easier and consistent th=
an the toolchain for PHP extensions in general, and NumPy didn't have to ad=
d overloads themselves as part of the extension (or teach Python devs the r=
ules around using them in general).
>
> So as another example, I'll pull up the math libraries in PHP. I maintain=
 a math library myself, but it isn't nearly as widely used as the works by =
Mark Baker. The mathematical uses have been described here as "niche" and "=
small". First let's see what Mark has to say about operator overloading (an=
d this RFC specifically):
>
> > Likewise, I have libraries for Matrix and Complex Numbers, where this w=
ould be an incredibly useful addition.... a similar RFC using magic was pro=
posed 6 years ago, and sadly never made it :-( I hope this time it is accep=
ted, especially as a new keyword feels better than magic
> - Source: https://twitter.com/Mark_Baker/status/1477957056464359427
>
> The libraries that Mark is referring to, markbaker/matrix and markbaker/c=
omplex, have over 105 million installs combined on packagist. (Source: http=
s://packagist.org/?query=3Dmarkbaker )
>
> > And so would `$lineValue =3D $unitPrice * $quantity;` work fine, with l=
ess words to read... and people who don't understand operator precedence wo=
uld have problems with more complex mathematical formulae whether it was op=
erator overloading or method name
> - Source: https://twitter.com/Mark_Baker/status/1478137583989309440
>
> > But why shouldn't it be `=3D=3D`... these are valid use cases for a com=
parison; equally, vector additions ($vector1 + $vector2) are quite commonpl=
ace in mathematics
> - Source: https://twitter.com/Mark_Baker/status/1478131480383606787
>
> Marco's response to the person who maintains the literal largest complex =
mathematics library in the entire language was:
>
> > Yeah, so use matlab?
>
> This is what I'm struggling with. I am seeing a lot of things here that s=
ound an awful lot like "that's not *my* use case, so no". That isn't how yo=
u design the language. Nikita's objection to the syntax is much easier for =
me to understand, because it is based on *language design*.
>
> Mathematics isn't something that is never used or never needed in PHP. Th=
e idea that I need to justify this statement is somewhat alarming.

I fully agree:
Any language should aim at doing math well, natively.
You should not have to want to go to another language for
calculations. If this is the case, the language is incomplete.
And I think modern PHP aims to be or become a "complete" language.

If people currently don't use the language for math problems, this
says more about the language than about the people.
There is a potential here to enable new packages that solve new
problems, that people would have done in another language in the past.

>
> I have provided not only a multitude of examples of use cases in the RFC,=
 but I have repeatedly done so on this list as well. I have provided exampl=
es in mathematics and examples in other domains, such as with Collections, =
with userland scalar objects. I've mentioned possible future scope to expan=
d further into things like better support for query builders. I do not beli=
eve the reason people vote no for this RFC is because they haven't been sho=
wn any use cases. The use cases are self-apparent and have *also* been prov=
ided, both within the current PHP ecosystem and outside of it. Both with ex=
isting extensions and userland libraries.
>
> I sincerely hope that the reason someone votes no on this RFC isn't becau=
se they think use cases don't exist or because the use cases are fringe. I =
also hope that it's not because of "abuse", as this is a boogeyman that is =
not supported by the ecosystems of nearly all languages with this feature. =
The problem is that without those two objections, I'm left with few reasons=
 I could see to vote no, perhaps the most prominent being the one Nikita ra=
ised with finding the syntax objectionable.
>
> The syntax offers a lot for future scope in my opinion, some of it not ev=
en related to operator overloads. It provides us a better way forward for a=
llowing objects to control casting, for instance. Many find the __toString(=
) implementation to be lacking. Controlled casting in C++ for example howev=
er is accomplished with something like `operator (int): int`. Another sugge=
stion that came through from the community after voting opened was to use s=
omething like `symmetric operator` to show that an operator can be in eithe=
r position. [..]

That was me :)
I suppose you are going to reply directly to that message.


> [..] It also could provide us with some way forward on improving/deprecat=
ing ArrayAccess.
>
> Burden on static analysis tools perhaps? But there are features that are =
difficult on static analysis that have been accepted. (Enums comes to mind.=
)
>
> If anyone is voting no truly because they are concerned that there aren't=
 use cases to justify it, I'd like to hear that and what sort of examples t=
hey are looking for, because I feel I have done this multiple times on this=
 list at this point.


Tbh, I had to warm up to the idea myself.
At first I only thought of all the potential problems that were
already mentioned here.

The main problem was I only thought of existing code, not of new code
to solve new problems.

-- Andreas



>
> Jordan