Re: Re: [RFC] Userspace operator overloading

On Thu, 12 Mar 2020 at 10:06, rowan.collins@gmail.com wrote:

On Thu, 12 Mar 2020 at 08:31, Jan Böhmer <jan.h.boehmer@gmx.de> wrote:

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

On 11.03.2020 at 10:22, Nikita Popov wrote:

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.

I have thought about this the last days, and I agree with you. Therefore I have removed this feature from the RFC.

I've been thinking about it as well, and am not sure what happens _without_ it in a case like this: # initial class, only overloads + on instances of itself class A { public static function __add(A $lhs, A $rhs) {

        // ...

} } # in some third-party library class B { public static function __add(A|B $lhs, A|B $rhs) {

        // ...

} } $a =3D new A; $b =3D new B; var_dump($b + $a); # calls B::__add($b, $a); OK var_dump($a + $b); # calls A::__add($a, $b), which is a TypeError If the engine doesn't catch the TypeError, it will never try B::__add($a, $b) in the second case, so presumably the TypeError will just be thrown to the user, which doesn't seem very helpful. Perhaps the simplest solution is to have a restriction that the operator overloads _must not_ specify types in their signature? Regards, Rowan Tommins

I have implmented your suggestion. If an operator handler has typehints, an error will be thrown, similar to the behavior if they would not have the required amount of arguments or were not static. The restriction that some functions can not declare typehints is not completly new, e.g. constructor must not declare a RETURN typehint, so I think it is not completly inappropriate to prevent your mentioned problems this way and I will most likely add this to the RFC. What do others think about this restriction? Furthermore I added a check that no arguments are passed by reference (like with other magic methods). We can not really prevent that a user manipulates passed objects (as they are always references), but at least for builtin values (int, string, etc.) it should not possible to modify their source. Also this would lead to problems, as the 1 in something like $a + 1 can not be passed as reference. Regards, Jan Böhmer