Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109266
MIME-Version: 1.0
References: <003701d6013c$9afe9750$d0fbc5f0$@gmx.de>
In-Reply-To: <003701d6013c$9afe9750$d0fbc5f0$@gmx.de>
Date: Tue, 24 Mar 2020 11:41:57 +0100
Message-ID: <CAF+90c9K5LHMiRp745O+oR7uS8QmkG0C037k7F6rv4Mt8+wXrA@mail.gmail.com>
To: =?UTF-8?Q?Jan_B=C3=B6hmer?= <jan.h.boehmer@gmx.de>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000093c56005a197673c"
Subject: Re: [PHP-DEV] [VOTE] Userspace operator overloading
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000093c56005a197673c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 23, 2020 at 6:58 PM <jan.h.boehmer@gmx.de> wrote:

> Hi internals,
>
> I have opened voting on
> https://wiki.php.net/rfc/userspace_operator_overloading, which allows
> users
> to overload operators in their own classes.
>
> Voting closes on 2020-04-06.
>
> Regards,
> Jan B=C3=B6hmer
>

To offer a counter-point, I voted yes on this proposal. A couple of
thoughts:

1. This is exposing functionality that already exists for internal classes
to userland classes. As a general rule, I think we should always strive to
have behavioral parity between internal and userland classes.

2. Because this just exposes existing functionality, the amount of
technical complexity this introduces is very small, especially compared to
the significance of what this enables. The implementation complexity of
RFCs is increasingly becoming a problem, due to the complex way in which
existing language features interact. This RFC does not fall into that
category.

3. As mentioned, this functionality already exists internally and is used
by GMP, where it works (imho) very well. Of course, this is also something
of a poster-child use case for operator overloading, in that the object
literally represents a number. But there are plenty other similar examples,
some of them very relevant to PHP (money represention).

I think there is a somewhat irrational fear that operator overloading is
going to be misused... but having worked in quite a few languages that do
support operator overloading, I think I've only encountered this in two
instances: First, the infamous use of << and >> as stream operators in C++
(which is really horrible, and gives operator overloading a bad name
everywhere). And second, the use of / as a path concatenation operator in
some libraries. And I think that's it. All other uses I've worked with were
things like arbitrary-precision integers, floats, decimals or rationals;
complex numbers, vectors, matrixes or tensors; bit vectors, constant
ranges, known bits representations.

Operator overloading is not a feature that is commonly needed or should be
used much, but it does tend to make code a *lot* more readable in the cases
where it is useful.

I think people might also find this blog post by Guido interesting:
https://neopythonic.blogspot.com/2019/03/why-operators-are-useful.html

Regards,
Nikita

--00000000000093c56005a197673c--