On 23.03.2020 at 18:58, [email protected] 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
