Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115657
MIME-Version: 1.0
References: <CAMrTa2EO-5nyoCYkHhMVxQ4nucRoHJj0=M=W22kUaW0jpHkHLg@mail.gmail.com>
 <f01eed58-6ccb-91a9-16d0-0f0c4e97d98a@gmail.com>
In-Reply-To: <f01eed58-6ccb-91a9-16d0-0f0c4e97d98a@gmail.com>
Date: Sat, 7 Aug 2021 13:07:24 -0700
Message-ID: <CAMrTa2E-pV+xP+3NJ=zd0S7N2agVRGiALaaJCBUaM=UwETEArw@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000025d96705c8fdb3e7"
Subject: Re: [PHP-DEV] Revisiting Userland Operator Overloads
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--00000000000025d96705c8fdb3e7
Content-Type: text/plain; charset="UTF-8"

> a) Treating operators as arbitrary symbols, which can be assigned any
operation which makes sense in a particular domain.
> b) Treating operators as having a fixed meaning, and allowing custom
types to implement them with that meaning.

I think this is the core design choice that will affect how the
implementation is approached, and having some good discussion around it
before I got into the implementation was the goal of this thread. :) Jan's
proposal for 8.0 fell more into the a) category with each symbol being
given an independent, unrelated, and unopinionated override. That RFC very
nearly passed, the vote was 38 for and 28 against.

My one hesitation in pushing for a b) type implementation right now (which
I favor slightly personally) is that the basic math operators do have very
different meanings between arithmetic, matrix/vector math, and complex
numbers, all of which are in the same domain of "math". Granted, only
objects which represent a number valid for arithmetic could also be used
with other math functions in PHP (such as the sqrt() or cos() functions).
However, they are definitely use cases that are well treaded in userspace
code and libraries.

Complex numbers, for example, couldn't implement a __compare() function at
all, as they don't have any consistent and sensical definition of "greater
than" or "less than". This means that if an object represented a complex
number, the following code would be perhaps unexpected to some:

if (10 < $complex) {
    // Never gets here
}

if (10 > $complex) {
    // Never gets here
}

if (10 == $complex) {
    // Never gets here (!!)
}

$comparison = 10 <=> $complex; // Nonsensical, should throw an exception

So while I tend to lean more towards a b) type implementation myself, even
within that I understood there to be some non-trivial considerations.
"Numbers" in PHP are obviously real numbers, instead of matrices or
complex, so all previous semantics of operators and math functions would
reflect that. To me, an ideal implementation of operator overloading would
be both:

1. Flexible about the contextual meaning of a given operator.
2. Somewhat opinionated about the semantical meaning of an operator.

This is obviously challenging to accomplish, which is why I'm leaving
myself nearly a whole year for discussion and implementation. I don't want
to do this quickly and end up with something that gets accepted because we
want some form of operator overloading, or something that gets rejected
again despite putting in a great deal of work.

Jordan

On Sat, Aug 7, 2021 at 12:07 PM Rowan Tommins <rowan.collins@gmail.com>
wrote:

> On 06/08/2021 17:34, Jordan LeDoux wrote:
> > 1. The only supported operators in the RFC will be the mathematical
> > operators: (+, -, /, *, **, %)
> > 2. The RFC would also provide an interface, (something like
> > MathObjectInterface), that has all the magic methods in it.
> > 3. The do_operation would be changed to check for the interface being
> > implemented instead of the specific method.
>
>
> Hi Jordan,
>
> In a previous thread [1], I wrote about two fundamental design
> approaches to operator overloading:
>
> a) Treating operators as arbitrary symbols, which can be assigned any
> operation which makes sense in a particular domain.
> b) Treating operators as having a fixed meaning, and allowing custom
> types to implement them with that meaning.
>
> Both approaches have their pros and cons, but my general impression is
> that approach (b) has more support on this list.
>
> For approach (b), I think your proposal to group operations into
> interfaces is a good one - it doesn't prevent someone using the
> operators to mean something completely different, but it expresses a
> clear opinion.
>
> I think using "+" for a union of two collections is really an example of
> approach (a) - it doesn't really mean "add", and it's no less arbitrary
> than using "<<" to add an item to a collection (as is conventional in
> Ruby, for instance).  If we want to go down that route, and allow
> individual operators to be overloaded, I think we should look for a
> syntax that lets you pick the symbol, rather than giving them names
> which only make sense in some contexts.
>
>
> [1] https://news-web.php.net/php.internals/108347
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

--00000000000025d96705c8fdb3e7--