Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121408
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-1019-ged83ad8595-fm-20231002.001-ged83ad85
MIME-Version: 1.0
Message-ID: <e4839349-b28f-46d9-b895-cc70b5c456fd@app.fastmail.com>
In-Reply-To: 
 <CAPzBOBNZTe6WFg_=mC8nP4FK10Lb=HXL5t4hU86odOG1SEPYdQ@mail.gmail.com>
References: 
 <CABAhh3FtvJ3TMF6R8Ot1o+OzS+SMOw37U3uehgCWPrP7guHB1A@mail.gmail.com>
 <CAPzBOBNZTe6WFg_=mC8nP4FK10Lb=HXL5t4hU86odOG1SEPYdQ@mail.gmail.com>
Date: Wed, 18 Oct 2023 16:42:53 +0000
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Custom object equality
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Oct 18, 2023, at 1:12 PM, Robert Landers wrote:
> On Wed, Oct 18, 2023 at 2:51=E2=80=AFPM someniatko <someniatko@gmail.c=
om> wrote:
>>
>> Hi internals,
>>
>> There is often a need to compare whether two objects are equal. For
>> example, a popular [brick/money](https://packagist.org/packages/brick=
/money)
>> library has a `Money` class, which has an `equals()` method. However,=
 this
>> becomes tedious to implement such methods, when multiple nested objec=
ts are
>> involved. For instance, Money has an amount and a currency.
>>
>> There were already suggestions on the mailing list to allow "overload=
ing"
>> existing `=3D=3D` operator, and some suggestions went even as far as
>> overloading `<`, `>=3D` etc operators. However, overloading existing
>> operators may lead to a BC break between the PHP version which does s=
upport
>> the functionality, and which doesn't. It won't result in a BC break i=
n case
>> it's an entirely new syntax, because a library or a project won't be =
able
>> to write code which overloads `=3D=3D` in say PHP 8.4, but with code =
which
>> still works in PHP 8.3 - it will have to require PHP 8.4+. But if it =
is
>> implemented as a magic method, then `=3D=3D` will work differently fo=
r 8.3 and
>> 8.4.
>>
>> I suggest thinking about introducing a new operator `~=3D`, which sig=
nifies
>> that custom equality is requested. In such a case,  `=3D=3D` will wor=
k as it
>> works now, and by default `~=3D` will work also like `=3D=3D`, unless=
 its
>> behavior is overwritten via a magic method. If a magic method is not
>> present in a class being compared, `~=3D` will compare two objects fi=
eld by
>> field, but using `~=3D` comparison rather than `=3D=3D` comparison, r=
ecursively.
>>
>> For instance, a Money object may consist of Amount and Currency. If t=
wo
>> Moneys are compared using `~=3D`, and Money does not implement a magic
>> method, Amount also doesn't implement it, but Currency does, then Amo=
unts
>> are compared using  `~=3D` which is equal to `=3D=3D` comparison in t=
his case,
>> but Currencies are compared using their custom comparison logic.
>>
>> This approach allows combining
>> - no BC break - `~=3D` is a new syntax which is unavailable in older =
PHP
>> versions
>> - explicitly showing an intent that objects are compared using a cust=
om
>> comparison, rather than standard PHP one
>> - allow to skip writing boilerplate equals() methods which just forwa=
rd
>> equals() to the nested objects
>> - standardize such comparisons on the language level
>>
>> Of course how exactly this operator looks may be changed, `~=3D` is j=
ust an
>> example.
>>
>> WDYT?
>>
>> Regards,
>> Illia / someniatko
>
> I like it.
>
> One thing I really like about this proposal is that, in theory, it
> could open the door to new operators like ~<, ~<=3D, ~!, ~=3D which ca=
n be
> similarly implemented.
>
> It also makes me wonder if something similar to scala can be
> implemented, where any operator beginning with "~" can just call an
> associated magic method. I'm not sure how it would be implemented
> though, since I don't think you can use symbols/operators in method
> names. But if you wanted a pipe operator, you could add one via ~|.
> It'd allow for more useful DSL's that are implemented in PHP, as
> currently, it doesn't really make sense to create a DSL that is
> actually PHP since you can't override any operators.
>
> That being said, my only criticism is that it will be really easy to
> forget the ~ when writing code. It's a true shame that overloading
> wasn't added to the language, as it makes it an impractical language
> for entire classes of problems/solutions.
>
> Robert Landers
> Software Engineer
> Utrecht NL

Honestly I'm still on team operator-override.  *Most* major languages ha=
ve operator overloading, and it doesn't seem to cause a problem.  (Accor=
ding 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.

More to the point, the key question is whether anyone who voted No on th=
e previous operator overloading RFC would vote Yes on an operator-overlo=
ading-but-only-with-an-opt-in-prefix RFC.  If not, then it doesn't reall=
y 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 alr=
eady have.

So the real question is: Would anyone who voted No on operator overloadi=
ng before vote Yes on it if it used ~=3D,  ~>, ~+, etc. instead?

---Larry Garfield