Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109288
To: jan.h.boehmer@gmx.de, 'PHP internals' <internals@lists.php.net>
References: <003701d6013c$9afe9750$d0fbc5f0$@gmx.de>
Message-ID: <379095fd-ba11-4d84-6cab-89905eeab32a@gmx.de>
Date: Wed, 25 Mar 2020 12:28:42 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <003701d6013c$9afe9750$d0fbc5f0$@gmx.de>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: quoted-printable
Subject: Re: [VOTE] Userspace operator overloading
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 23.03.2020 at 18:58, jan.h.boehmer@gmx.de wrote:

> I have opened voting on
> https://wiki.php.net/rfc/userspace_operator_overloading, which allows us=
ers
> to overload operators in their own classes.

It seems to me that the RFC is not sufficiently specific enough
regarding the concatenation of instances of classes which implement
__toString().  The RFC itself doesn't mention that explicitly, and the
backward incompatible changes section states:

| As long as the user does not implement, the operator magic functions,
| operators on objects will behave in the previous way.

However, at least the current implementation raises two notices ("You
have to implement the __concat function") when concatenating Stringable
objects.

A minor issue: in my opinion, introducing
PHP_OPERAND_TYPES_NOT_SUPPORTED doesn't make sense.  The RFC says:

| Handlers can specify return typehints, but note that the return type
| has to be nullable (as PHP_OPERAND_TYPES_NOT_SUPPORTED has the value
| null).

So if we ever wanted to change the value of
PHP_OPERAND_TYPES_NOT_SUPPORTED, we'd introduce a BC break.  Therefore
the constant's value likely will never change, so using NULL directly to
signal unsupported operand types would be fine, wouldn't it?

=2D-
Christoph M. Becker