Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121416
MIME-Version: 1.0
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>
Date: Wed, 18 Oct 2023 14:42:22 -0300
Message-ID: <CADK1yX+uqxmb0m11qnd4wSffz1xeWeUS=rVtPYNdU+J8-Mwpyw@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000008f35230608012b94"
Subject: Re: [PHP-DEV] Custom object equality
From: deleugyn@gmail.com (Deleu)

--0000000000008f35230608012b94
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 18, 2023 at 2:05=E2=80=AFPM Christian Schneider <cschneid@cschn=
eid.com>
wrote:

> Am 18.10.2023 um 18:42 schrieb Larry Garfield <larry@garfieldtech.com>:
> > So the real question is: Would anyone who voted No on operator
> overloading before vote Yes on it if it used ~=3D,  ~>, ~+, etc. instead?
>
> I confess that I'm not a fan of operator overloading for a language like
> PHP but introducing new operators on top of making them overloadable seem=
s
> a bad idea. Operators have the problem of being hard to look up and
> prefixing them with ~ feels like the worst of both worlds.
>
> Regards,
> - Chris
>

To add on to this, the proposal side-steps a potential BC break issue while
introducing a collection of problems for libraries using PHP Tokens, Static
Analysers, IDEs and more importantly the ability to grep your codebase
looking for `=3D=3D`.

From what I understood about the BC break concern, it's the fact that IF:

- Existing code is comparing objects (relying on potentially
non-deterministic behavior?)
- PHP introduces operator overload
- A library releases a new major version implementing operator overload
- Existing code breaks

Sounds to me that this is more between Library authors and Library users.
Yes, PHP would be opening the door for potential BC breaks, but the
stability of Composer packages and the adoption of Semantic Versioning
throughout the industry makes this look like PHP is trying to protect
grown, trained, mentally stable adults from running with knives.

On Wed, Oct 18, 2023 at 1:43=E2=80=AFPM Larry Garfield <larry@garfieldtech.=
com>
wrote:

> Honestly I'm still on team operator-override.  *Most* major languages hav=
e
> operator overloading, and it doesn't seem to cause a problem.  (According
> to my research, C++, Kotlin, Swift, Rust, C#, Haskell, Python, and Ruby a=
ll
> 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.
>
> ---Larry Garfield
>

To argue against myself, I think Larry has a killer point in the language
comparison. I think it's fair to say PHP is the weird one out for not
having Operator Overload when even Python and Ruby (languages more similar
to PHP than Kotlin or Rust) have them.

Ultimately, if voters think it's best to overload `~=3D` instead of `=3D=3D=
`, I
think we bite the bullet and deal with the consequences. Even though I have
every reason not to want `~=3D`, PHP deserves method overloading unless fol=
ks
can show facts as to why nearly every other major programming language is
wrong or why they can have it and we can't.


--=20
Marco Deleu

--0000000000008f35230608012b94--