Re: [VOTE] Userspace operator overloading

On 23.03.2020 at 18:58, jan.h.boehmer@gmx.de wrote: > I have opened voting on > https://wiki.php.net/rfc/userspace_operator_overloading, which > allows users > to overload operators in their own classes. It seems to me that the RFC is not sufficiently specific enough regarding the concatenation of instances of classes which implement __toString(). The RFC itself doesn't mention that explicitly, and the backward incompatible changes section states: | As long as the user does not implement, the operator magic functions, | operators on objects will behave in the previous way. However, at least the current implementation raises two notices ("You have to implement the __concat function") when concatenating Stringable objects. A minor issue: in my opinion, introducing PHP_OPERAND_TYPES_NOT_SUPPORTED doesn't make sense. The RFC says: | Handlers can specify return typehints, but note that the return type | has to be nullable (as PHP_OPERAND_TYPES_NOT_SUPPORTED has the value | null). So if we ever wanted to change the value of PHP_OPERAND_TYPES_NOT_SUPPORTED, we'd introduce a BC break. Therefore the constant's value likely will never change, so using NULL directly to signal unsupported operand types would be fine, wouldn't it? -- Christoph M. Becker