Re: [PHP-DEV] [VOTE] Userspace operator overloading

This is only part of a thread. view whole thread
  109266
March 24, 2020 10:41 nikita.ppv@gmail.com (Nikita Popov)
On Mon, Mar 23, 2020 at 6:58 PM boehmer@gmx.de> wrote:

> Hi internals, > > I have opened voting on > https://wiki.php.net/rfc/userspace_operator_overloading, which allows > users > to overload operators in their own classes. > > Voting closes on 2020-04-06. > > Regards, > Jan Böhmer >
To offer a counter-point, I voted yes on this proposal. A couple of thoughts: 1. This is exposing functionality that already exists for internal classes to userland classes. As a general rule, I think we should always strive to have behavioral parity between internal and userland classes. 2. Because this just exposes existing functionality, the amount of technical complexity this introduces is very small, especially compared to the significance of what this enables. The implementation complexity of RFCs is increasingly becoming a problem, due to the complex way in which existing language features interact. This RFC does not fall into that category. 3. As mentioned, this functionality already exists internally and is used by GMP, where it works (imho) very well. Of course, this is also something of a poster-child use case for operator overloading, in that the object literally represents a number. But there are plenty other similar examples, some of them very relevant to PHP (money represention). I think there is a somewhat irrational fear that operator overloading is going to be misused... but having worked in quite a few languages that do support operator overloading, I think I've only encountered this in two instances: First, the infamous use of << and >> as stream operators in C++ (which is really horrible, and gives operator overloading a bad name everywhere). And second, the use of / as a path concatenation operator in some libraries. And I think that's it. All other uses I've worked with were things like arbitrary-precision integers, floats, decimals or rationals; complex numbers, vectors, matrixes or tensors; bit vectors, constant ranges, known bits representations. Operator overloading is not a feature that is commonly needed or should be used much, but it does tend to make code a *lot* more readable in the cases where it is useful. I think people might also find this blog post by Guido interesting: https://neopythonic.blogspot.com/2019/03/why-operators-are-useful.html Regards, Nikita
  109287
March 25, 2020 11:23 nicolas.grekas+php@gmail.com (Nicolas Grekas)
> 1. This is exposing functionality that already exists for internal classes >
2. Because this just exposes existing functionality, the amount of
> technical complexity this introduces is very small >
> 3. As mentioned, this functionality already exists internally and is used > by GMP, where it works (imho) very well. >
Thanks Nikita for the insights, that's really helpful. I'd suggest removing the "PHP_OPERAND_TYPES_NOT_SUPPORTED" constant and settle on null instead. The reason is visible in the RFC: `public static function __mul($lhs, $rhs): ?Vector3` - nothing else than null can be returned here when looking at the return type. Returning a const is just calling for "WTF" indirections IMHO. I'm still voting yes, hoping for this const to be removed after if the RFC passes, if it does :) Nicolas