On Sat, 15 Feb 2020 at 23:06, <jan.h.boeh...@gmx.de> wrote: > Hi internals, > > based on the discussions here (https://externals.io/message/108300) and > here > (https://github.com/php/php-src/pull/5156), I have created a proper RFC > for > userspace operator overloading: > https://wiki.php.net/rfc/userspace_operator_overloading > > The main differences to my original concept, is the removed __compare() > method (comparison overloading is a complex topic and should be handled in > a > different RFC) and the possibility to signal that the operator handler does > not support the given types (by typehints or returning a special value). > This way, only one of both objects has to know about the other type. This > should expand the use case of operator overloading compared to my old > concept. > > What do you think about the RFC? > > Some discussion points, I can think of, would be the naming of the methods > (maybe naming them after the operator symbol and not the arithmetical > operation they represent, e.g. __plus instead of __add) or putting the > methods inside of interfaces like done for ArrayAccess (But I don’t see any > advantage in doing so, as it is very difficult grouping different operators > in a single interface usefully. Also, operators can accept and return > different types, so there is no real common interface between classes you > could rely on). > Furthermore, maybe the idea of allowing operator overloading in general > should be discussed as it is sometimes considered an anti-pattern (e.g. the > usage of '<<' for outputting a string in C++). On the other hand there are > many languages and libraries where operator overloading is used > successfully > (e.g. numpy in Python). > > Regards, > Jan Böhmer > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > Just as a FYI, I'll vote No to this RFC regardless of arguments as I find operator (and method) overloading a bad idea in general. Moreover, the only ones I am a tiny bit less reluctant to overload are the mathematical operators.
However, one of the major reasons to want to have this seems to add better support for Matrices and Complex number which can already be done at the extension/engine level. Best regards George P. Banyard
