Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125621
Message-ID: <3f6d4409-d370-4391-a8e5-a8a50d8da793@gmx.de>
Date: Wed, 18 Sep 2024 16:19:02 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads
 (again)
Content-Language: de-DE
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>, internals@lists.php.net
References: <CAMrTa2E2m00gOoGy5FbvkrLwM1AUP3ZmJXHkxh_R2qEszQ=NWA@mail.gmail.com>
 <2551c06a-ec1f-4870-a590-aeb5752fc944@rwec.co.uk>
 <CAMrTa2FLJwjwy9uGpRJJJFMUD1vs=vqzv8x2VxMsYeBqMN4m9Q@mail.gmail.com>
 <0f0444eb-8fc5-4c56-8528-5aa528988e73@rwec.co.uk>
 <e4c478c5-03b5-4cfd-95c4-6161d88557fa@app.fastmail.com>
 <12de3d03-3426-44f8-a83f-d686d2034912@rwec.co.uk>
In-Reply-To: <12de3d03-3426-44f8-a83f-d686d2034912@rwec.co.uk>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
UI-OutboundReport: notjunk:1;M01:P0:/9CyVvydgn8=;oPnPNefM5/gJEO7M091PaLGIo0t
 8LH6PaBs7wO2g0rS5Tv3fr8L45oOWRp7T83sEXJcVDERw093UaEReAX2VxUdUqgIVLe1rtFAq
 wqi1VBJxgjKVQfC5QO3OLgwbjwrP2IOkhOPHxCBTpPTQ8Ypi/549elnCKi2iUi0ZL8/qSUbFh
 LBoK9tj8RM0DeOa6OybsR3GjpbUeGCCfHuGNtn0nM45R61iugSnISg850qP0hTZyzTtgSYK7o
 MeqtBCZIf5YZjEGTYMsQ/DCj6Cp0arKWuf9FaEeB5ExHdCBC8hL09bTbbYQPwSo6hGa4Fqdtq
 uAFakEr/hxCOzvoOzyUlMEwIJcWg/FCo7rodfjnw6K2/9C0JHNnWqcyl7ex48+dwjZZO+AAZ5
 e34zEes9XzfxpqnXOOH5YuHowlrw3uOCo9bGZVYNHrFZdhZen3DsrhAIeEgsZ2Ba0en+XjvVI
 8+1ilSNANX59gro0YwsnPVxUsPql3APMvD7uc3sB1OiPp/8R9rv4quX6OsZnap3C+s6wqF2wy
 xWgT1MRiyatbDFxfUmP7ikjTsiythfvsYyhXYsm74DW6Q7HHhM3A7iy2YI6o0fp7wJzZTb7D0
 act29Yl6YTFv7CS6j2fSWDIYTxFcURtD+ptsbIBmN3ow9WkxNBs0v0oEoBJYuSb/M4YYAw3ye
 rFX9jL6XKanKUpr+Dc+ebBmJiiaXFS1JF1kUY7dfGq0G6zCHXgQQfb02a8WpSXoznx/QTC6//
 66RdH7qUfSA7Z0eJBhEbKwI0ZVeYCKSdRqqgXFZ65c4h63bcB3kCI7Wq5x3+/yeOad1nzL1T6
 Vg1KPPvY38aiZX8m2GaX2O+IzygneFkeXpGMidV0c0KKw=
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 18.09.2024 at 00:13, Rowan Tommins [IMSoP] wrote:

> Since you mentioned Scala, I looked it up, and it seems to be on the
> other end of the spectrum: operators are just methods, with no
> mathematical meaning or special dispatch behaviour. In fact, "a plus b"
> is just another way of writing "a.plus(b)", so "a + b" is just a way of
> writing "a.+(b)"
>
> Maybe it would be "useful enough" to just restrict to left-hand side:

In my opinion, this is the only reasonable way to implement operator
overloads in PHP.  It is easy to understand, and what can easily be
understood is easy to explain, document, and to reason about.  I do not
understand why we're talking about commutative operations; even the
inconspicuous plus operator is not commutative in PHP
(https://3v4l.org/nQcL5).  Those who want to implement an numerical
tower (or whatever) can still implement the operations as being
commutative (where appropriate) by doing manual double-dispatch.  Yeah,
doesn't fit with scalars, but where is the actual problem?  And I
wouldn't want to restrict the functionality of overloading *exiting*
operators.  If a library completely goes overboard with operator
overloading, either only few will use it, or it might be a fantastic
tool of which nobody of us could have even thought of.

Now, comparison operators pose a particular issue if overloads where
implemented this way, namely that the engine already swaps them; there
are no greater than (or equal) OPcodes.  However, this already doesn't
work for uncomparable values, yielding "surprising" results (e.g.
#15773).  As such, it might be worth considering to have a separate PR
regarding (overloading of) comparison operators.

And I would consider equality operator overloading as yet a different
issue, since that operation is (or at least should be) inherently
commutative.  What we have now, however, is not that helpful, and breaks
encapsulation (https://3v4l.org/hTR2v); although without that it would
be completely useless.

Christoph