Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108614
Date: Sun, 16 Feb 2020 01:54:21 +0000
User-Agent: K-9 Mail for Android
In-Reply-To: <003801d5e44c$169700e0$43c502a0$@gmx.de>
References: <003801d5e44c$169700e0$43c502a0$@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: internals@lists.php.net
Message-ID: <83988BB2-7C9D-4118-A1A2-253725F1A7EA@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Userspace operator overloading
From: rowan.collins@gmail.com (Rowan Tommins)

On 15 February 2020 22:05:52 GMT+00:00, jan=2Eh=2Eboehmer@gmx=2Ede wrote:
>Some discussion points, I can think of, would be the naming of the
>methods
>(maybe naming them after the operator symbol and not the arithmetical
>operation they represent, e=2Eg=2E __plus instead of __add) or putting th=
e
>methods inside of interfaces like done for ArrayAccess


As I mentioned earlier [1] I think the answers to both of these questions =
depend on a fundamental philosophical question about what you're overloadin=
g:

- The groups of operations which exist for built-in types e=2Eg=2E the ari=
thmetic operations overloaded by GMP; or string operations overloaded by an=
 object with enhanced Unicode functionality=2E

- The individual symbolic operators, with no intrinsic meaning - e=2Eg=2E =
overloading =2E for concatenation on strings but dot-product for vectors; o=
r a DSL overloading << and >> for "into" and "out of"=2E

I think it would benefit the RFC to take a stance on that question, and bu=
ild the feature around it=2E


[1] https://news-web=2Ephp=2Enet/php=2Einternals/108347

--=20
Rowan Tommins
[IMSoP]