Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116667
MIME-Version: 1.0
References: <CAMrTa2FB-EVGq29oLCU8fYkMYi+KsQiEAFv1xxMFO7vnm8e6=Q@mail.gmail.com>
 <44b3fb4b-4693-1639-c8c0-5e17296c196e@gmail.com> <CAMrTa2E9STK3G52mnQ9UsrUqi_bH4SMUzcE76PEGcxcLzGPVZA@mail.gmail.com>
 <4b58c011-ed87-ba87-201d-0cf8e4116c6f@processus.org> <CAB-BujbjgBBNdLjf+8SxWKJrv3J3CU8Mv51n4AkCwpsOt5WekA@mail.gmail.com>
In-Reply-To: <CAB-BujbjgBBNdLjf+8SxWKJrv3J3CU8Mv51n4AkCwpsOt5WekA@mail.gmail.com>
Date: Thu, 16 Dec 2021 22:22:57 -0800
Message-ID: <CAMrTa2Fk2R8PB77Ws7dcfwRw-NWfmH4AzJkNgehA1WR4Nr1StQ@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a8b3f105d351924b"
Subject: Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--000000000000a8b3f105d351924b
Content-Type: text/plain; charset="UTF-8"

On Thu, Dec 16, 2021 at 4:21 AM Andreas Hennings <andreas@dqxtech.net>
wrote:

>
> Having one side of the operator "own" the implementation feels wrong,
> and could lead to problems with inheritance down the line.
>
> From C++ I remember that at the time, there was a philosophy of
> defining and implementing these kinds of operations outside of the
> objects that hold the data.
>
>
This makes sense in C++ because they are all statically typed and compiled,
but the types of many things in PHP are not necessarily known until
runtime, so it's a bit different. First, there is no situation in which the
overloads will ever be called outside the context of an object instance.
Any situation that would trigger a lookup for overloads will involve an
object instance that has a value of some kind.

`$val = $obj + 5;`

They are not static methods because they *aren't* static methods in the
engine execution context. Making them static would break scope needlessly
in direct calls (if those are ever made), and would be a lie within the
engine. Python is a language that handles them exactly in this manner.

Under future scope I have a section titled Polymorphic Handler Resolution
that addresses the issue of inheritance. I decided to make that a separate
future scope for two reasons:

1. It has some unique efficiency and optimization concerns around resolving
the inheritance structure during an operator opline. In general developers
expect operators to be very, very fast operations. Overloaded operators
will always be slower, but adding inheritance checks would exacerbate that.
I wanted to consider that separately so that it could receive its own focus.
2. For those who have limited personal experience with operator overloads
in the context of object instances (basically, those who haven't used
Python or something similar), the reason for that requirement might be
difficult to see. It will be easier to demonstrate the need to voters on
this list after this RFC is implemented I think. There's already a lot of
domain-specific background to this. The + operator *isn't* commutative in
PHP right now, for instance. If you want to see how, consider `array +
array`. Whether an operator is commutative is *always* domain dependent.

The main edge-case that will be addressed by this future scope is:

`$val = $parent + $child;`

Where `$child` is a descendent of `$parent`, and both implement *different*
overloads. In such a case, you want to execute the overload of the child
class. An example of this would be a `Number` class and a `Fraction` class
that extends `Number`. You would want to execute the overload on `Fraction`
regardless of whether it was the left or right operand. This is how the
instanced overloads behave in Python as well. I plan on bringing that as a
follow up RFC before 8.2 feature freeze if this RFC passes.

--

As a note, I have been swayed by the comments of many others at this point
to make operator implementations callable directly on objects, and remove
the callable restriction on them. The RFC has been updated to reflect this,
and I will update the PR for it as well when I have the time.

Jordan

--000000000000a8b3f105d351924b--