On 11.03.2020 at 10:22, Nikita Popov wrote: > On Fri, Mar 6, 2020 at 9:17 AM Jan Böhmer <jan.h.boeh...@gmx.de> wrote: > >> Am 02.03.2020 um 15:30 schrieb Nikita Popov: >> >>> On Thu, Feb 27, 2020 at 9:43 PM <jan.h.boeh...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php