Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108619
MIME-Version: 1.0
References: <003801d5e44c$169700e0$43c502a0$@gmx.de>
In-Reply-To: <003801d5e44c$169700e0$43c502a0$@gmx.de>
Date: Sun, 16 Feb 2020 13:28:10 +0100
Message-ID: <CAFPFaMKQYGsWqkd03CCmSwwxQK5edSWDS3tLV4AdNKnkEHjYag@mail.gmail.com>
To: jan.h.boehmer@gmx.de
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000001dd083059eb093f3"
Subject: Re: [PHP-DEV] [RFC] Userspace operator overloading
From: george.banyard@gmail.com ("G. P. B.")

--0000000000001dd083059eb093f3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, 15 Feb 2020 at 23:06, <jan.h.boehmer@gmx.de> wrote:

> Hi internals,
>
> based on the discussions here (https://externals.io/message/108300) and
> here
> (https://github.com/php/php-src/pull/5156), I have created a proper RFC
> for
> userspace operator overloading:
> https://wiki.php.net/rfc/userspace_operator_overloading
>
> The main differences to my original concept, is the removed __compare()
> method (comparison overloading is a complex topic and should be handled i=
n
> a
> different RFC) and the possibility to signal that the operator handler do=
es
> not support the given types (by typehints or returning a special value).
> This way, only one of both objects has to know about the other type. This
> should expand the use case of operator overloading compared to my old
> concept.
>
> What do you think about the RFC?
>
> Some discussion points, I can think of, would be the naming of the method=
s
> (maybe naming them after the operator symbol and not the arithmetical
> operation they represent, e.g. __plus instead of __add) or putting the
> methods inside of interfaces like done for ArrayAccess (But I don=E2=80=
=99t see any
> advantage in doing so, as it is very difficult grouping different operato=
rs
> in a single interface usefully. Also, operators can accept and return
> different types, so there is no real common interface between classes you
> could rely on).
> Furthermore, maybe the idea of allowing operator overloading in general
> should be discussed as it is sometimes considered an anti-pattern (e.g. t=
he
> usage of '<<' for outputting a string in C++). On the other hand there ar=
e
> many languages and libraries where operator overloading is used
> successfully
> (e.g. numpy in Python).
>
> Regards,
> Jan B=C3=B6hmer
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Just as a FYI, I'll vote No to this RFC regardless of arguments as I find
operator
(and method) overloading a bad idea in general. Moreover, the only ones I a=
m
a tiny bit less reluctant to overload are the mathematical operators.

However, one of the major reasons to want to have this seems to add better
support for Matrices and Complex number which can already be done at the
extension/engine level.

Best regards

George P. Banyard

--0000000000001dd083059eb093f3--