Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108617
Date: Sun, 16 Feb 2020 10:31:14 +0000
User-Agent: K-9 Mail for Android
In-Reply-To: <f454366b-08fe-b12b-9b23-ea4466d0801b@gmail.com>
References: <003801d5e44c$169700e0$43c502a0$@gmx.de> <83988BB2-7C9D-4118-A1A2-253725F1A7EA@gmail.com> <f454366b-08fe-b12b-9b23-ea4466d0801b@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: internals@lists.php.net
Message-ID: <2E0E7D03-0742-42CD-8C0C-F663CA5E8E90@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Userspace operator overloading
From: rowan.collins@gmail.com (Rowan Tommins)

On 16 February 2020 05:07:03 GMT+00:00, Stanislav Malyshev <smalyshev@gmail=
=2Ecom> wrote:
>Hi!
>
>> - The individual symbolic operators, with no intrinsic meaning - e=2Eg=
=2E
>> overloading =2E for concatenation on strings but dot-product for
>> vectors; or a DSL overloading << and >> for "into" and "out of"=2E
>
>Please no=2E I know it looks fancy and some languages love it, but for a
>person not in on the joke reading such code is a nightmare

:) I know you're not alone in that feeling=2E If it turns out this is the =
majority view, I think it answers a couple of open questions:

Overload methods should definitely be named after operations, not symbols,=
 to remind people they are implementing addition, not giving new meaning to=
 +

They should probably be grouped into interfaces, which this RFC has so far=
 resisted=2E How often does it make sense for a type to support addition bu=
t not subtraction, or multiplication but not division? Even more clearly, i=
f a type claims to implement bitwise OR but not bitwise AND, NOT, and XOR, =
something is definitely fishy=2E

You can't stop people using overloading DSL-style, but you can make it obv=
ious that it's not the intention of the feature (if we agree that it's not =
the intention; maybe some people here are really hoping to use it that way?=
)

Regards,

--=20
Rowan Tommins
[IMSoP]