Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109287
MIME-Version: 1.0
References: <003701d6013c$9afe9750$d0fbc5f0$@gmx.de> <CAF+90c9K5LHMiRp745O+oR7uS8QmkG0C037k7F6rv4Mt8+wXrA@mail.gmail.com>
In-Reply-To: <CAF+90c9K5LHMiRp745O+oR7uS8QmkG0C037k7F6rv4Mt8+wXrA@mail.gmail.com>
Date: Wed, 25 Mar 2020 12:23:43 +0100
Message-ID: <CAOWwgpmR5shAivRriTAQKgAEy1vGbyYU6UVR-N4j4LWCdKgMWg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: =?UTF-8?Q?Jan_B=C3=B6hmer?= <jan.h.boehmer@gmx.de>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000008a6b9a05a1ac1a22"
Subject: Re: [PHP-DEV] [VOTE] Userspace operator overloading
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--0000000000008a6b9a05a1ac1a22
Content-Type: text/plain; charset="UTF-8"

> 1. This is exposing functionality that already exists for internal classes
>

2. Because this just exposes existing functionality, the amount of
> technical complexity this introduces is very small
>


> 3. As mentioned, this functionality already exists internally and is used
> by GMP, where it works (imho) very well.
>

Thanks Nikita for the insights, that's really helpful.

I'd suggest removing the "PHP_OPERAND_TYPES_NOT_SUPPORTED" constant and
settle on null instead.
The reason is visible in the RFC: `public static function __mul($lhs, $rhs):
?Vector3` - nothing else than null can be returned here when looking at the
return type. Returning a const is just calling for "WTF" indirections IMHO.

I'm still voting yes, hoping for this const to be removed after if the RFC
passes, if it does :)

Nicolas

--0000000000008a6b9a05a1ac1a22--