On Mon, 6 Apr 2020 at 20:36, <jan.h.boeh...@gmx.de> wrote: > > Hi internals, > > I have closed the voting. With 38 in favor and 28 against the RFC is DECLINED > (didn’t reach the needed 2/3 majority for a new feature). > > Thanks to everyone who has participated. >
Hi Jan, Thanks for running the RFC. Although it didn't quite pass it seems a lot closer now. Apologies for not taking part in the discussion earlier, but I'm slow at thinking. To follow up on a couple of things. > If it can not handle the given type, it has to return the > constant PHP_OPERAND_TYPES_NOT_SUPPORTED (currently just null). This does not appear to be a good choice. It means that to evaluate whether the code is safe to call the code needs to be evaluated. That makes doing static code analysis very difficult. Also, it means that operators could not return null as a result of the operation, which seems like an odd choice that would be a regretful limitation. Rowan Tommins wrote from https://externals.io/message/108788#108993 : > > > $a = new A; > $b = 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 And jan.h.boeh...@gmx.de wrote: > > If an operator handler has typehints, an error will be thrown, > What do others think about this restriction? I think that is the wrong solution to the wrong problem. It's a wrong solution because parameter types* are a useful tool both for program correctness at runtime, they make it easier to run static code analysis tools on the code and most importantly they save a lot of developer time, mostly through autocomplete. It's the wrong problem because that code does have a TypeError. It is calling '__add' and passing a parameter to the method that the code can't handle. It appears to be the same error case as: ``` class A { public function add(A $lhs, A $rhs) {...} } class B { public function add(A|B $lhs, A|B $rhs) {...} } $a = new A; $b = new B; $b->add($a); // Ok $a->add($b); // TypeError ``` For me, the solution to the error in this code is not "remove the parameter type on A::add". I'm pretty sure that the solution to this type of error would be "fix your code". When someone looks at the idea of userspace operator overloading again, I think the following path might reach a more acceptable solution. * Encourage people to use parameter types to make their code easier to reason about. * Encourage people to use static analysis to check their code for errors, including errors where they have invalid operands to operations. * Take the approach in the RFC that passing a wrong parameter type to an operator magic method represents a programming error that cannot be handled in the normal program flow, and that throwing an exception is the right thing to do here**. But as most people should be using parameter types, and static analyzers to check for this type of error, this should not occur. Other than a learned reticence against throwing exceptions, what downsides would that have? cheers Dan Ack * PHP has parameter types that are checked at runtime, not 'hints' that can be worked around as found in other programming languages. If people would stop using the phrase 'type hint', it would make the conversation more accurate. ** This is not using exceptions for flow control (though it could be abused for it). Most people should be avoiding these problems through writing code correctly, and using static analysis to double-check their code is free from errors. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
