Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109392
To: Andrea Faulds <ajf@ajf.me>, internals@lists.php.net
References: <003701d6013c$9afe9750$d0fbc5f0$@gmx.de>
 <7a83f950a31d94d5ff2307ac8219db3b7b6482b6.camel@schlueters.de>
 <CANZOY=Cre6iCUskSWoic1D22s197b553i+tp5hBK_iuiFo_=cA@mail.gmail.com>
 <12ad7c71-8958-7742-12c4-e83e359c8186@gmx.de>
 <php.internals-109387@news.php.net>
Message-ID: <e16f2857-3c6b-7197-c80e-6637cfeec6f1@gmx.de>
Date: Sat, 28 Mar 2020 16:16:10 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <php.internals-109387@news.php.net>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE] Userspace operator overloading
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 28.03.2020 at 14:29, Andrea Faulds wrote:

> Christoph M. Becker wrote:
>
>> This "try left/right" approach is how operator overloading works for
>> internal classes[1], and apparently, it works quite well, as long as it
>> is not overused.
>
> I think =E2=80=9Cas long as it is not overused=E2=80=9D are the key word=
s there. We have
> a very limited number of internal classes with operator overloading
> right now, and the authors know about what other such classes exist and
> therefore can design with them in mind. But once any userland PHP class
> can use operator overloading, you could start seeing uses of operators
> where the left- and right-hand side are classes from unrelated libraries
> whose authors were not aware of eachother, and that could create strange
> problems when one or the other library is updated with operator overload
> handling.
>
> Consider Arnold's example:
>
> =C2=A0=C2=A0=C2=A0 $a + $b + $c - $d
>
> We are not constraining operator overloading to just be for number-like
> objects, it can in principle be used for absolutely anything.

And floats can be used to store monetary values, and to do calculations,
and apparently, that is actually done by some.  Was it a bad idea to
introduce floats to the language?

> $a here
> might have an overload that works for any right-hand-side object, but
> then once $b adds its own similar overload in a new version, the code no
> longer does the same thing when it's flipped around ($b + $a), violating
> the normal expectation that `+` is commutative, and that's before
> considering what $c and $d might do!

If, for example, the + operator is overloaded to add something to a
collection, the normal expectation that + is commutative is already
violated.  Operator overloading should definitely not be used for
"anything", but only for those rare cases which resemble math operations
(frankly, I would not have not supported __concat() at all).  Also,
overloaded operators should be programmed defensively, i.e. they should
not accept arbitrary arguments (how could that even work?), but only
those they can handle.  If implementations adhere to these "rules", I
don't see real issues.

=2D-
Christoph M. Becker