Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108319
To: "'Nikita Popov'" <nikita.ppv@gmail.com>
Cc: "'PHP internals'" <internals@lists.php.net>
References: <00ea01d5d630$b18d4f20$14a7ed60$@gmx.de> <CAF+90c8h8dBhM=12ifxBJsWGcgVkjXHmmvKkPo_xCjUvZ++XdQ@mail.gmail.com>
In-Reply-To: <CAF+90c8h8dBhM=12ifxBJsWGcgVkjXHmmvKkPo_xCjUvZ++XdQ@mail.gmail.com>
Date: Wed, 29 Jan 2020 15:39:55 +0100
Message-ID: <012f01d5d6b1$f975a590$ec60f0b0$@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQKXoxxQn2bR4QXrsNNx7hJjE1ZW5AKdGYKYpmklXMA=
Content-Language: de
Subject: RE: [PHP-DEV] Operator overloading for userspace objects
From: jan.h.boehmer@gmx.de

> I would recommend not handling overloading of comparisons in the same =
proposal. Comparison is more widely useful than other overloading and =
has a more complex design space (especially when it comes to =
accommodating objects that can only be compared for equality/inequality =
for example). Comparison may also benefit more from having an interface =
than the other operators.

I understand your point. There was already an RFC with an similar idea =
(https://wiki.php.net/rfc/comparable). I think the idea of having an =
comparable interface could be really useful for things like sorting =
algorithms (so these could sort any comparable object). The case that =
structures must not define an order (but can have equality) is a good =
point, maybe this could be solved with two interfaces Comparable (which =
defines the spaceship operator) and another one like Matchable or =
Equalable (which only defines an is_equal function). I would not split =
the comparison operators any further (the RFC mentioned above even =
suggested to overload the not equal operator) or we end up with =
situations, where $a!=3D$b is not the same as !($a=3D=3D$b), which would =
make the code using it very difficult to understand.

It is maybe reasonable to split operator and comparison overloading into =
different RFCs so they can be discussed separately. But if PHP decides =
to offer operation overloading it should also offer a possibility to =
compare custom objects, or the operation overloading looses some of its =
intended convenience (like the situation in PHP 7.0 where you could =
define scalar type hints, but could not allow passing null easily).

> Of course there are performance concerns here, and it could in some =
cases be significantly more efficient to perform an in-place =
modification. It is possible to allow that while still keeping the above =
semantics by only allowing an in-place modification if $a has no over =
users (something that we can check in the VM). But I don't think this =
should be part of an initial proposal.

I agree. If there is real need for this case, it could be implemented =
later.

> Unfortunately, this implementation goes in the wrong direction: PHP =
already has full internal support for operator overloading through the =
do_operation object handler. Operator overloading should be exposed to =
userland through that handler as well.

I have seen this mechanism too late, and I have to understand a bit more =
how it works exactly, but I agree that this internal operator =
overloading mechanism should be used. I think it should be the goal that =
internal and userspace classes should appear the same to the user in =
points of the operator overloading, so an user can just call for example =
parent::__add() if he is extending a PHP class (e.g. Carbon does that =
for the datetime class). I will try to build an implementation using the =
do_operation handler, when I have time.

> Thanks for working on this :) I think overloaded operators are a =
reasonable addition to the language at this point. I think the main =
concern people tend to have in this area is that operator overloading is =
going to be abused (see for example << in C++). There are many very good =
use-cases for operator overloading though (as mentioned, vector/matrix =
calculations, complex, rationals, money, ...) Some of those are not =
common in PHP, but maybe the lack of operator overloading is part of the =
problem there ;)

Ultimately we cannot really control how people will end up using the =
operation overloading, but in my opinion the benefits outweighs the =
drawbacks (also hopefully nobody would be insane enough to replace the =
print function with << ;) ).
With FFI-bindings it would be possible to build cool math/calculation =
libraries (similar to numpy in python), that can be accessed easily via =
PHP and does big calculations in native speed. I don=E2=80=99t think PHP =
will become an scientific used language like python, but sometimes some =
higher math function in PHP could be helpful. Also at least the handling =
of money values is quite common in web applications.