Re: Revisiting Userland Operator Overloads

Le 06/08/2021 à 18:34, Jordan LeDoux a écrit :

Hey all, ... Hello,

I'm sorry I couldn't answer the last few weeks I was on vacation. I just wanted to say, I'm opposed to user-land operator overloading for a few reasons: * it may produce shorter, simpler code, but it hides the real logic behind, * not all mathematical arithmetic operators have a semantic meaning for let's say, collections: it's not evident to me that "/" means partition (even thought the "+" for union is trivial), * they are hundreds different operations on collections which have a common taxonomy in many languages, there will never be enough operators for all, we will end up with Frankenstein API's where there will be operators for some operations, and methods for others, * methods in plain english (or whatever is your language) are always more readable in the end, * you can CTRL+click to navigate (in a decent IDE) on a method call, not on an operator, * step-debugging will be a bumpy ride, * some people will use them good, many will misuse them, some will do evil with those, * and hell, if "->" doesn't mean "access that object member" anymore, but "hey, the implementor could do anything at all instead", sky will fall upon us. I'm not sure the benefice-risk ratio is good enough. That said, in the other side, I'm +1 with equals(), compareTo() and those kind of magic methods for the "==" and comparison functions, this is something that PHP lacks, but I'm unsure this worth making all operators user-land overridable. I'm always favorable to something that makes the code being semantically and non-ambiguous to read, and in my opinion userland operators create more mess than they solve, they basically encourage people to make non-readable stupid shortcuts in their code. Best regards, Pierre