Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116628
MIME-Version: 1.0
References: <CAMrTa2FB-EVGq29oLCU8fYkMYi+KsQiEAFv1xxMFO7vnm8e6=Q@mail.gmail.com>
 <CA+kxMuQqGpkuqwFLrW29G38aOUNbvXM6Dq=P8NXt=1zai_=zxA@mail.gmail.com> <7126a5cb-fdaf-4e50-b8af-7d95965d1125@www.fastmail.com>
In-Reply-To: <7126a5cb-fdaf-4e50-b8af-7d95965d1125@www.fastmail.com>
Date: Sun, 12 Dec 2021 18:56:32 +0000
Message-ID: <CA+kxMuROkHkVVWd0AFDweQBBNqXCkPmGqJVggGduDF6=KyZEgg@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)
From: Danack@basereality.com (Dan Ackroyd)

On Sat, 11 Dec 2021 at 17:46, Larry Garfield <larry@garfieldtech.com> wrote=
:
>
> Using symbols, however, would (with some future extension to make it exte=
nsible) allow for:

I don't get how it's easier, other than being able to skip naming the
symbol name. e.g. adding union and intersection operators

function __union(...){}
function __intersection(...){}

vs

operator  =E2=88=AA(...){}
operator =E2=88=A9(...){}

In fact, I find one of those quite a bit easier to read...

Larry Garfield wrote:
> It uses effectively the same operator sigil, though.

Yes, that's what I was trying to say.

Danack wrote:
> The name of the function (e.g. __add) always refers to the symbol used
> where it is used, not what it is doing.

If the naming is taken from the sigil, then it's always appropriate.

So if operator * has the magic method __asterisk instead of __mul, it
avoids any suggestion of what the operation actually means for the
object.

btw, I don't really care about this naming problem. My concern is that
it's being used as a reason for introducing a special new type
function, when it's really not a big enough problem to deserve making
the language have special new syntax.

cheers
Dan
Ack