Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115678
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
In-Reply-To: <FE49BA62-2CAE-4446-AE56-B231A23015D3@newclarity.net>
Date: Mon, 9 Aug 2021 17:41:55 -0400
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <67A0B22A-428F-4A2C-9198-63C0A772FFA2@newclarity.net>
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>
To: Jordan LeDoux <jordan.ledoux@gmail.com>
Subject: Re: [PHP-DEV] Revisiting Userland Operator Overloads
From: mike@newclarity.net (Mike Schinkel)

On Aug 9, 2021, at 5:32 PM, Mike Schinkel <mike@newclarity.net> wrote:

> On Aug 9, 2021, at 1:48 PM, Jordan LeDoux <jordan.ledoux@gmail.com> =
wrote:
> You claim that this would be documented on php.net and this would be =
sufficient. Yet the DateTime class has had operator overloads for =
comparison operators since 5.2 and there is still *zero* mention on =
php.net (that I am aware of or can find) of this. Not even a mention =
that it exists, let alone what the override behavior is. *Not even in =
the god-awful comments on the manual.*

Improving documentation is an easier fix than adding a complex language =
feature. And a key difference is (almost?) anyone who is motivated can =
contribute to the docs; not so for adding language features.=20

For example, why is it not an option for you to update the docs for =
DateTime and DateInterval if the docs are bad? Or other classes that =
have could have operator overloading in the future?

> Simply put, as someone who has spent my entire career working =
primarily in PHP and been working in it since PHP 4, it has one of the =
very best free and online manuals for any language I've worked in, and I =
would still 10 times out of 10 prefer to be able to see the =
implementation in my IDE than have to look it up on php.net.

So are you arguing that PHP should have no library functionality and =
have everything implemented in PHP?=20

I don't mean to commit a reductio ad absurdum, but I am honestly =
confused by your need to see the implementation of behavior in PHP that =
is well-known and well-established in science and business. =20

I honestly don't get why it would be important to see the internals of =
DateTime and DateInterval class, or a ComplexNumber or a Money class for =
that matter. Why can't that just be documented, other than your claim =
that "docs are bad?" =20

Why it will be important to see operator overloading implementations in =
PHP when you don't see sin() and cos(), for example?

This really feels like a personal preference and not a driving need for =
everyone. But if others agree that seeing operator overloading in PHP =
code is critical, please do speak up and, for my edification, please do =
explain why.

>  What I mean is that there would be multiple "number like" abstract =
classes that would be 80% to 90% similar. That is, if it actually =
correctly represented the core math ideas. This method however would =
utterly fail for unit based value overloads, of which Rowan's money =
example is a specific case.

Yeah, I don't see this as a problem.  Internally if there are a lot of =
similarities than the similarities can be shared by a common function.=20=


Duplication is not a problem in an of itself. If you only have to write =
it once and rarely ever need to maintain it.

> However, creating abstract classes simply for custom operator =
overloads would signal to users that this is something internals is =
willing to do. Despite the fact that I am confident the process would =
continue to work, I would very much anticipate multiple and continuous =
threads opened by users wondering when "their" operator overloads are =
going to be included. While this obviously doesn't force anything, it =
absolutely is a distraction.

That is in part of why I asked for use-case examples, to see if there =
really were a lot of use-cases where operator overloading makes sense.  =
You only provided two categories; Math and the already existing =
DateInterval.=20

It's not like operator overloading is a feature which without developers =
literally cannot implement functionality. Even though you (currently) =
cannot compose an expression of objects like `$cn1 + $cn2` doesn't keep =
you from implementing `$cn1.add($cn2)`.

Let us assume that because we were to create operator overloads for =
DateTime and DateInterval and for your Math needs people started =
inundating the list with requests to add hundreds of other classes (I =
really doubt that would happen, but I'm running with it anyway.)=20

One easy answer is for the list to come up with a checklist for operator =
overloading concerns and request those asking to present userland =
libraries that would want operator overloading and show how the =
libraries would address the concerns in the checklist. Once done, then =
the list could review and make a decision.

OR, *if* the list really is inundated with requests, maybe we *then* =
realize there are many use-cases, and we move towards a generic operator =
overloading. =20

But as of today I am not convinced that there are really that many =
use-cases for operator overloading that would not just be a leaky =
abstraction.

(As an aside, how are we going to implement operator overloading in =
DateTime and DateInterval within PHP?  Do we have to subclass just to =
get them to have operators?  So minimally, we should start with those =
two and write it in C for PHP core.)

>> https://medium.com/@rwxrob/operator-overloading-is-evil-8052a8ae6c3a
> I was hoping for something more concrete than what he said in this =
article, especially when the one and only comment on the article =
succinctly expresses why it's incorrect.

The one and only comment expresses the commenter's opinion, not "why =
it's incorrect." =20

You dismiss the author's points you disagree even though he wrote a full =
post that also references why the Go language designers choose to avoid =
operator overloading but you attribute much greater authority to the =
drive-by commenter who simply states an opinion you agree with.=20

When it boils down to it, it's all just opinion. I included his link =
because you strong implied that nobody has issues with operator =
overloading in Python while that post illustrates that some people do =
have issues with operator overloading in Python.

> Python's major "selling point" over other languages, especially for =
its initial adoption and wide use in teaching, is its power in =
scientific computing, and those libraries 100% *depend* on Python's =
operator overloading.

Different languages have different selling points. The features needed =
to make Python a really good maths language are not the same features =
that are needed for building robust, reliable, and maintainable web =
applications. And features that make a language good for one use-case =
can make it less good for another, which is what I especially believe =
about operator overloading.

Operator overloading is useful for languages that are intended for =
implementing DSLs. Open question: do we collectively want PHP to be able =
to be a strong language for writing DSLs?  (If yes, I have a slew of =
features I'll be asking for.)

Honest question:  If Python is so much better for math and you appear to =
be a math guy, why are you using PHP?  What are your use-cases where you =
can't just use Python?

>  Respectfully I disagree. There can be different meanings for __add() =
with different operands, just like `2 + 3` is different than `2.1 + =
3.1`. But an operator heavily implies the idea that there is a single =
and deterministic result for a given set of input values and input =
types. I do not believe that these are at all similar to _toArray().

They are both syntax sugar for calling methods.  And they are both =
methods userland developers may not have the time or the expertise to =
handle properly. =20

And I am not talking down to userland developers;  *I* do not have the =
expertise to address the issues in a maths library.=20

> The fact that internals cannot anticipate what they are because the =
domains and context are varied is not the same as the results being =
non-deterministic or usage dependent. They are not arbitrary in the same =
way that array structure is.

However, you are actually making my point, which is that since they are =
so deterministic then why is there the need for flexibility to be done =
in userland vs. the standardization that could be could be better in PHP =
core? For the latter we can ensure the abstractions are not leaky and =
the requirements are fully addressed.

> That's not exactly what my concern is, though I can also understand =
that concern. My concern is that I think I can properly advocate for and =
explain the use cases and implementations that would benefit my own =
work, but I do not know that others could be able to do so.

That seems a rather thin justification for adding a complex language =
feature which we could potentially wish we had not.

Anyway, you can always stick around to champion their needs.

>  This is why I'm targeting this for 8.2 and started this conversation =
nearly a full year before the feature freeze for 8.2. I am not going to =
come through with the RFC vote in a few weeks, this is going to be slow, =
deliberate, and inclusive, because that is the only sensible way that a =
change as complex and impactful as what I'm proposing could be done =
correctly.

Why don't we start with this?  Rather than initially focus on the syntax =
for creating operator overloading why don't we start by focusing on the =
known use-cases and come up with documentation showing how those =
use-cases would leverage the custom operators?  Fully map them out.=20

If we do that and we still get general operator overloading then at =
least userland will have a roadmap for how to get started with operator =
overloading for the known use-cases rather than lots of developers =
seeing a shiny new feature that they all start adding to their code, =
badly.

You can easily create this doc on GitHub and solicit PRs from others far =
and wide for their use-cases.

> This is interesting, since we *do* have operator overloads for =
DateTime already and have for quite a long while. This is covered =
briefly in the draft RFC I linked in my last message.

We have some operators, but not all the useful ones.

> An imaginary number literal couldn't really be supported without =
either a fully-featured complex number library in core (not just an =
abstract stub with operator overloading), or errors/exceptions on =
multiple operator combinations.

It would help me if we could discuss this in specific terms rather than =
abstract terms.  What does "fully-featured complex number library" mean? =
 Can you create a Gist showing what the class interfaces would look like =
in PHP code?=20

> For instance, `int + imaginary` would require some representation of =
complex number as a result type. This is, to my understanding, why this =
is usually left to userland implementations in most languages, =
particularly since complex numbers are advantageous to represent as `int =
+ imaginary` in some circumstances and `(r, theta)` in other =
circumstances.

Correct me as I may be wrong, but isn't int+imaginary a function of (r, =
theta) and vice-versa?

If yes, I assume that both representations could be generated by the =
same ComplexNumber class?

>   This is a point that I obviously can't casually dismiss, because =
it's simply a fact. Once user defined operator overloading exists, it =
can't reasonably be undone, however it can always be added on top of =
abstract classes in the future. That being said, this is not something =
that internals hasn't considered before *and* there already are custom =
operator overloads in C implementations in PHP.

The custom operator overloads in C require a lot more skill and =
experience to implement than in PHP which I am arguing is a benefit =
related to operator overloading. =20

Further, only people who are not using managed hosting that constrains =
the extensions used are able to use these extensions.  So these =
overloaded operators are not infecting PHP code far and wide.

> There are also extensions that cover more domain specific C =
implementations, such as ext-decimal and ext-gmp. The first version of =
this feature that I'm aware of was worked on for 7.1.

This seem to me to be the perfect example of how to move forward with a =
Maths library.

> So while your point is valid and powerful, my contention isn't that =
you're wrong, but rather that now *is* later for this feature.
>=20
> I am not dismissing your point here, but I'd like to respectfully =
suggest that we now have the information to address the topic, instead =
of needing further use cases to consider.

We have differing opinions on that, so we should agree to disagree on =
that subjective assessment.=20

> DateTime already has overloads for comparison operators and has for a =
long time.=20

stdClass objects also support equals comparison so really this is more =
about add, subtract operators which DateTime and TimeInterval do not =
have.=20

Which brings up this question: If we allow comparison operator =
overloading for objects does that DateTime comparisons might no longer =
mean they are the same pointer but instead a userland comparison?  If =
yes, that actually chills me to the bone.

https://3v4l.org/2RCot#v8.0.9

> In fact, the operator overloading for GMP done by Nikita for 5.6 =
covered much of the same arguments (though it obviously didn't include =
userland operator overloading).

Exactly. More of Nikita's approach is what I am advocating for.

> Finally, as I mentioned I won't be entertaining that format for this =
RFC. While I have said that I understand the argument, I would suggest =
that those who feel it is a better alternative work on it as an RFC if =
they believe it is a better route. This RFC may take me the entire year =
and still get rejected, and I understand that.

That's absolutely fine and understood. That's the way it works for PHP.

Similarly I will advocate others consider fleshing out specific =
use-cases and ideally have us implement a few before we consider adding =
generic operator overloading to PHP. =20

Unless of course I find that there is a strong consensus to move forward =
with generic operator overloading in which case I will demure.  But thus =
far it is not clear which way that wind actually blows.

> "why is this use case given preferential treatment?" and I will be =
unable to answer because I would raise the same objection myself.

My answer would be "Because there is someone championing this use-case =
and not for other use-cases." #fwiw.

Given our dialog, maybe we can meet half-way?  Since it's a year out as =
you say, why not go ahead and start documenting the use-cases and how =
operators would be used for those use-cases? =20

Like I said above, that work will need to be done by someone eventually =
if generic operator overloading is added; better to do it once and share =
than have each developer have to redo on their own. And I might even =
become more supportive if I can see that choices that need to be made =
regarding operator overloading are more obvious than I am currently =
assuming.

-Mike