Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121420
Message-ID: <360b0cc0-505e-4865-b9a5-7f4f0a362dd0@bastelstu.be>
Date: Wed, 18 Oct 2023 20:45:52 +0200
MIME-Version: 1.0
Content-Language: en-US
To: internals@lists.php.net
References: <CABAhh3FtvJ3TMF6R8Ot1o+OzS+SMOw37U3uehgCWPrP7guHB1A@mail.gmail.com>
 <CAPzBOBNZTe6WFg_=mC8nP4FK10Lb=HXL5t4hU86odOG1SEPYdQ@mail.gmail.com>
 <e4839349-b28f-46d9-b895-cc70b5c456fd@app.fastmail.com>
In-Reply-To: <e4839349-b28f-46d9-b895-cc70b5c456fd@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Custom object equality
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

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