Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115688
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> <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>
In-Reply-To: <3D7F74C1-F1A0-4258-8EE3-3C143B6B54EB@newclarity.net>
Date: Tue, 10 Aug 2021 21:06:31 -0700
Message-ID: <CAMrTa2F_1qjhwUbN8WaeN83+H2hh+8AJt8QO4U3mpokZOjZaRw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000061c6a205c940be23"
Subject: Re: [PHP-DEV] Revisiting Userland Operator Overloads
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--00000000000061c6a205c940be23
Content-Type: text/plain; charset="UTF-8"

On Tue, Aug 10, 2021 at 8:46 PM Mike Schinkel <mike@newclarity.net> wrote:

>
> Either way if PHP can identify a value object then it could limit operator
> overloads to just classes that are value objects by whatever approach PHP
> chooses to distinguish.
>
>
> -Mike
> [*] Ironically I mentioned you because I thought you would be appreciate
> seeing another reason PHP could benefit from value objects. But as they
> say, no good deeds go unpunished.
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Here is a quick and dirty example of just the complex number use case. It
assumes that the operator overloads already are built in. A couple of
things of note:

1. The actual mathematical logic to cover all the possible input and return
types is extensive. Though the execution time and complexity are quite
limited, the code complexity is high due to the number of conditionals.
2. I chose to implement the various operator overload functions in
different ways to illustrate different methods that might accomplish the
same task in userland code. For instance, in some cases I typed against the
SimpleNumber abstract, while in others I expanded SimpleNumber out into its
concrete implementations, Real and Imaginary.
3. I only implemented the _add() and __mul() methods for this example, as
the reality is that getting into some of the more complex operations would
be so much code that it wouldn't be a digestible example. The __pow()
method for ComplexNumber would be in excess of 100 lines and also require a
polar coordinate representation within the class, for instance.

This isn't a working implementation, in that this code will produce errors
if run in PHP (due to the absence of operator overloads). Please note that
if we were to go the route of creating domain-specific classes to cover
this use case, the actual classes would be many, many times longer than
this. This is some of the simplest logic involved in this particular use
case, which is why I chose it as the example, and that perhaps illustrates
why I am willing to explore such objects but do not believe they are the
best choice at this time.

https://github.com/JordanRL/operator-overloading-rfc/tree/master/use-cases/complex-numbers

Jordan

--00000000000061c6a205c940be23--