Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115680
MIME-Version: 1.0
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>
In-Reply-To: <FE49BA62-2CAE-4446-AE56-B231A23015D3@newclarity.net>
Date: Mon, 9 Aug 2021 17:49:20 -0700
Message-ID: <CAMrTa2FvG=J+9iU=UzMdYeX8-swRjPGD9Q4tc6zEMNvS3Sg2pw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000043d96405c929dfd9"
Subject: Re: [PHP-DEV] Revisiting Userland Operator Overloads
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--00000000000043d96405c929dfd9
Content-Type: text/plain; charset="UTF-8"

On Mon, Aug 9, 2021 at 2:32 PM Mike Schinkel <mike@newclarity.net> wrote:

> 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.
>
>
They are deterministic for given *values* and *types*. They are not
deterministic over the whole category.


>
> 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.
>
> 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.
>
>
I have the stub RFC on github:
https://github.com/JordanRL/operator-overloading-rfc

However your suggestion is an excellent one. I will add some interfaces and
abstract classes to that repository when I am able to illustrate what user
implementations (or the PHP expressions of the C implementations) might
look like.


>
> 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?
>
>
I mean that it would need to be a complex number literal or object that
fully understood its relationship to other literals and to the operators.
The interfaces, if you ignore typing, would be similar to other number
classes, but the *implementations* would be very different. That's the
biggest problem with providing say a single abstract number class that has
built in operator overloading. Unless it can then be extended and
overridden, in which case it seems that it will result in much more heinous
misusage to me than simply doing generic operator overloading.


>
> 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?
>
>
Yes you're correct. The values of both representations are computed when
changed in my own ComplexNumber class, and the most advantageous one in
terms of algorithmic complexity is used for calculation in any given method.


>
> 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.
>
> 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.
>
>
The overloaded operators don't interfere with anything *at all* unless you
use an object that has them defined, even if you use the extensions. The
GMP operator overloads don't affect anyone unless they are using GMP. These
will be the same, in that the operators are unaffected unless a class opts
in to using the feature.


>
> We have differing opinions on that, so we should agree to disagree on that
> subjective assessment.
>
>
Alright.


> stdClass objects also support equals comparison so really this is more
> about add, subtract operators which DateTime and TimeInterval do not have.
>
> 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
>
>
The identity comparisons (`===` and `!==`) were two comparisons that I
specifically planned to exclude from this RFC.


>
> 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.
>
> 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.
>
>
And I wouldn't expect it to be clear at this point. I was reaching out now
more to gather a list of preferences and concerns for the feature. Perhaps
the best way to think about what I was looking for was the answers to these
questions:

1. If anyone planned to vote against such an RFC regardless of
implementation, details, or need, why? Could I understand what those
concerns are.
2. Supposing that the feature were guaranteed for inclusion, what are the
preferences of the people on this list for limitations, implementation
details, and structure.
3. If anyone with deeper knowledge of the PHP source had some pointers for
me on auxiliary things that would need to be changed with this RFC, I was
hoping they would be mentioned. (For instance, I'm aware of DateTime's
overrides and did not plan on converting them to extendible generic
overrides.)


>
> 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?
>
> 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.
>

Yes, I have the stubs of that work outlined in the RFC github I linked, and
I will put some effort in over the next week to create some mock classes
and interfaces to illustrate the use cases.

Jordan

--00000000000043d96405c929dfd9--