Re: [RFC] Userspace operator overloading
| From: | Rowan Tommins | Date: | Sun, 16 Feb 2020 10:31:14 +0000 |
| Subject: | Re: [RFC] Userspace operator overloading | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-108617@lists.php.net to get a copy of this message | ||
On 16 February 2020 05:07:03 GMT+00:00, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>Hi!
>
>> - The individual symbolic operators, with no intrinsic meaning - e.g.
>> overloading . for concatenation on strings but dot-product for
>> vectors; or a DSL overloading << and >> for "into" and "out
>> of".
>
>Please no. 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. 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. How often does
it make sense for a type to support addition but not subtraction, or multiplication but not
division? Even more clearly, if a type claims to implement bitwise OR but not bitwise AND, NOT, and
XOR, something is definitely fishy.
You can't stop people using overloading DSL-style, but you can make it obvious 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,
--
Rowan Tommins
[IMSoP]