Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109284
MIME-Version: 1.0
References: <003701d6013c$9afe9750$d0fbc5f0$@gmx.de>
In-Reply-To: <003701d6013c$9afe9750$d0fbc5f0$@gmx.de>
Date: Wed, 25 Mar 2020 11:44:38 +0100
Message-ID: <CAEPJdumzOzGck2C6nc65sqQxyvUHS55n5DsgAhViU9myHrsh0Q@mail.gmail.com>
To: jan.h.boehmer@gmx.de
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c9def705a1ab8e1b"
Subject: Re: [PHP-DEV] [VOTE] Userspace operator overloading
From: kontakt@beberlei.de (Benjamin Eberlei)

--000000000000c9def705a1ab8e1b
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
>

Thank you.

I voted yes on this for similar reasons than Nikita. I think it is
confusing to users why internal objects can overload these and userland
can't.

The simplicity of exposing this is another plus.

The potential for misuse is a non issue for me, because essentially this
applies to most features, especially with existing magic methods we have a
precedent that we can build upon instead of "repressing use".

>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--000000000000c9def705a1ab8e1b--