Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121423
MIME-Version: 1.0
References: <CABAhh3FtvJ3TMF6R8Ot1o+OzS+SMOw37U3uehgCWPrP7guHB1A@mail.gmail.com>
 <f90cb6db-d816-4a90-86d4-2760b7e721c8@processus.org> <CAMrTa2EHx3-WG_7qAPYSVRFJxs+DzFbMRd=0jtiHi1UdH+Oa_Q@mail.gmail.com>
In-Reply-To: <CAMrTa2EHx3-WG_7qAPYSVRFJxs+DzFbMRd=0jtiHi1UdH+Oa_Q@mail.gmail.com>
Date: Wed, 18 Oct 2023 22:45:25 +0200
Message-ID: <CAPzBOBOCu7S28PZqGMpCAMhEc+-awJLbs3_Mtrf8M-YVG4zTrQ@mail.gmail.com>
To: Jordan LeDoux <jordan.ledoux@gmail.com>
Cc: Pierre <pierre-php@processus.org>, someniatko <someniatko@gmail.com>, 
	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: landers.robert@gmail.com (Robert Landers)

On Wed, Oct 18, 2023 at 10:22=E2=80=AFPM Jordan LeDoux <jordan.ledoux@gmail=
.com> wrote:
>
> On Wed, Oct 18, 2023 at 6:03=E2=80=AFAM Pierre <pierre-php@processus.org>=
 wrote:
>
> > 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 =
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?
> >
> > 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 litera=
lly
> > 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 wrot=
e
> the gigantic operator overload RFC the last time it was proposed, I do no=
t
> 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 ar=
e
> 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 featur=
es
> 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 an=
d
> 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

As a user of PHP, it was sad to see that fail. There are no "unsigned
longs" in PHP, and I had to create a library that emulated them using
GMP. There is no way to describe how terrible using that library
was... simply because you couldn't overload a plus sign or an equals
sign. Accidentally using real operators could cause all kinds of
shenanigans and invalid math being done. Fun times.

If it had been a possibility, we would have ditched PHP immediately.
We almost did anyway, even if it meant rewriting everything.

People seem to be hung up on "people might abuse it" and forget there
are real-world, somewhat niche problems that are True Pain (TM) to
solve without overloading. Pain enough to leave the language entirely.

Thank you for your contribution, it was a really well-put-together
RFC, IMHO. I would have voted for it if I could have.

Robert Landers
Software Engineer
Utrecht NL