Re: Re: [RFC] Userspace operator overloading

On 11.03.2020 at 10:50, Christoph M. Becker wrote:

On 11.03.2020 at 10:22, Nikita Popov wrote:

On Fri, Mar 6, 2020 at 9:17 AM Jan Böhmer <jan.h.boehmer@gmx.de> wrote:

Am 02.03.2020 um 15:30 schrieb Nikita Popov:

On Thu, Feb 27, 2020 at 9:43 PM <jan.h.boehmer@gmx.de> wrote:

If the operator handler function declares typehints (e.g. public static function __add(Vector3 $lhs, int $rhs)), the function handler is not called if the operand types do not match the signature, and the other operand's handler is tried to call.

I'm somewhat skeptical about this. This smells of method overloading, and we don't do method overloading. There is no other place in PHP that would perform dispatching based on the method signature, even if in this case it's not a choice between multiple methods on the same class, but rather multiple methods on different classes. Some of the usual problems of method overloading don't apply here (in particular, one could make a reasonable argument that the method on the first object should be chosen, even if there is a more specific signature available on the second object), but I'm skeptical about introducing this kind of special case in the language specification.

Your point about the "smell of method overloading" is interesting. In my opinion this mechanism makes it a bit easier to use operator overloading as you dont have to do tedious typecheckings on your own in simple cases. But I agree that this behavior is a bit odd compared to other PHP features.. That feature is not really needed for operator overloading, as you can use the PHP_UNKNOWN_OPERAND_TYPES const for signaling that the handler does not support the given types. If you (the internals developers) says that this does not fit into the concept of PHP, I will remove it from my RFC (or put it in a separate votation, if wished).

Does anyone else have thoughts on the ability to specify the supported types in the signature?

I agree that we should not introduce (this special case of) overloaded functions. Thanks, Christoph

I have thought about this the last days, and I agree with you. Therefore I have removed this feature from the RFC. If PHP perhaps gets real function overloading someday, we could consider then to integrate operator overloading like in other languages (a separate handler for each type combination), which would be much more useful than the mechanism I had proposed. If there are no other open discussion points, I would put the RFC to voting in the next days. Thank you for your feedback, Jan