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 dont 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
