On Thu, 12 Mar 2020 at 10:06, rowan.coll...@gmail.com wrote:
On Thu, 12 Mar 2020 at 08:31, Jan Böhmer <jan.h.boeh...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
