Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121422
MIME-Version: 1.0
References: <CABAhh3FtvJ3TMF6R8Ot1o+OzS+SMOw37U3uehgCWPrP7guHB1A@mail.gmail.com>
 <f90cb6db-d816-4a90-86d4-2760b7e721c8@processus.org>
In-Reply-To: <f90cb6db-d816-4a90-86d4-2760b7e721c8@processus.org>
Date: Wed, 18 Oct 2023 13:22:22 -0700
Message-ID: <CAMrTa2EHx3-WG_7qAPYSVRFJxs+DzFbMRd=0jtiHi1UdH+Oa_Q@mail.gmail.com>
To: Pierre <pierre-php@processus.org>
Cc: someniatko <someniatko@gmail.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f772c40608036647"
Subject: Re: [PHP-DEV] Custom object equality
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--000000000000f772c40608036647
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 18, 2023 at 6:03=E2=80=AFAM Pierre <pierre-php@processus.org> w=
rote:

> Le 18/10/2023 =C3=A0 14:50, someniatko a =C3=A9crit :
> > Hi internals,
> >
> > This approach allows combining
> > - no BC break - `~=3D` is a new syntax which is unavailable in older PH=
P
> > versions
> > - explicitly showing an intent that objects are compared using a custom
> > comparison, rather than standard PHP one
> > - allow to skip writing boilerplate equals() methods which just forward
> > equals() to the nested objects
> > - standardize such comparisons on the language level
> >
> > Of course how exactly this operator looks may be changed, `~=3D` is jus=
t an
> > example.
> >
> > WDYT?
>
> I'm not fond of operator overloading, I actually quite hate it, I like
> the expressiveness of an equals() method.
>
> I would very much prefer to have a set of standard interfaces such as
> Comparable { compareTo($other): int } or Equatable { equals($other):
> bool; } which the standard API and userland libraries could make use of.
>
> In all cases, I don't like the ~=3D choice because in my mind it literall=
y
> translates to "is approximately/barely/maybe comparable to".
>
> By the way, please  do not use abbreviations such as WDYT, I'm not a
> native english speaker and I don't know all abbreviations, I had to
> duckduckgo' it.
>
> Regards,
>
> --
>
> Pierre
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
While I (obviously) appreciate the goal of the proposal here since I wrote
the gigantic operator overload RFC the last time it was proposed, I do not
support this idea here for one very simple reason: it is a clunky,
work-around implementation to try and get the benefits of operator
overloads without actually doing it.

The need to control comparisons is real and obvious. So long as voters are
categorically opposed to actual operator overloads no matter the
implementation, as represented here by you Pierre but by no means a
position that only you hold, I don't think we should be looking for ways to
get the functionality through hacks like this. It may get passed in the
short term and get PHP developers the equality comparison control that
objects desperately need, but it makes all future improvements almost
impossible to do.

someniatko:

If voters don't want operator overloads, then voters don't get the features
of operator overloads. It's very much that simple. If you want this
feature, try and change minds (ha ha good luck). "Operator overloads don't
fit a language like PHP"... despite the fact that Python is the language
most like PHP in many ways and has some absolutely crazy operator
overloads. "Operator overloads make operators impossible to understand"...
despite the fact that this is already the case with existing operators and
magic methods. "There is no use case"... despite the fact that this gets
suggested by a different person like clockwork AT LEAST every version
because it is something they would use.

Honestly I would give up on advocating for operator overloads someniatko
and just move to a language that has them like Python. That's what I did.
Your sanity will thank me.

Jordan

--000000000000f772c40608036647--