On Thu, Dec 16, 2021 at 4:21 AM Andreas Hennings <andr...@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
