On 15/02/2020 22:05, 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 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
I have changed the proposed names for the bitshift handlers to '__lshift' and '__rshift' (instead of __sl and __sr) to make more clear what operator is handled by the method (also the method names are now mostly consistent with the Python equivalents). How many of you would prefer a interface solution for operator overloading? I wonder if the RFC voting should include the option to choose between either the magic method approach (with the syntax proposed in the current RFC version) or using interfaces. For an interface version I would suggest these interfaces: ArithmeticOperators (implements +, -, *, /), PowOperator (**), ModuloOperator (%), ConcatOperator (.) and BitwiseOperators (~, &, |, ^, <<, >>). What would be appropriate names for the interface methods? If we just name them after the operation (like add()), it will become difficult to integrate these interfaces into existing code, as add() is already a used function name in many cases, but uses a different signature (non-static with one argument, whereas the interface needs a static one with two arguments). Regards, Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
