Hi
On 10/18/23 18:42, Larry Garfield wrote:
Honestly I'm still on team operator-override. *Most* major languages have operator
overloading, and it doesn't seem to cause a problem. (According to my research, C++,
Kotlin, Swift, Rust, C#, Haskell, Python, and Ruby all have operator overloading. Go,
TypeScript, PHP, and Javascript do not. Java has comparison-only overloading so it's in
the middle.) Most of the "it causes so many problems" arguments are, from what
I can tell, greatly over-exaggerated.
To clarify here: Haskell does not have operators per se. It has
functions whose name may consist of symbols only. It also has function
overloading via its typeclass feature (roughly comparable to
interfaces). It also allows to write any binary function in infix form
by wrapping it into backticks.
More to the point, the key question is whether anyone who voted No on the
previous operator overloading RFC would vote Yes on an
operator-overloading-but-only-with-an-opt-in-prefix RFC. If not, then it
doesn't really buy us anything. If so, then it's possible as a compromise but
would, frankly, be strictly inferior to just using the native operators we
already have.
So the real question is: Would anyone who voted No on operator overloading before
vote Yes on it if it used ~=, ~>, ~+, etc. instead?
I did not vote, but I would not vote in favor of operator overloading
with a different syntax. My main issue with operator overloading via
instance methods is that it's too easy to achieve a non-symmetric
equality, i.e. `$a == $b` != `$b == $a`.
This is a somewhat common problem of Java's `.equals()` method, unless
you are careful with how you write the implementation (e.g.
https://stackoverflow.com/a/6518645). At least for `.equals()` it would
be obvious that it would be an instance method and that it might not be
symmetric.
Operator overloading is only a value-add to me, if it would be realized
via free-standing functions to ensure there is a single canonical
implementation for a given operator, instead two different ones with
inverted parameter order. And yes, I realize that this would require
function overloading.
------------
I would be in favor of allowing writing binary functions in infix
position to allow stuff like '($foo bcadd 5)', because I can see how
that is more readable than `bcadd($foo, 5)`
Best regards
Tim Düsterhus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
