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
