Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116653
Message-ID: <4b58c011-ed87-ba87-201d-0cf8e4116c6f@processus.org>
Date: Thu, 16 Dec 2021 09:23:47 +0100
MIME-Version: 1.0
Content-Language: en-US
To: internals@lists.php.net
References: <CAMrTa2FB-EVGq29oLCU8fYkMYi+KsQiEAFv1xxMFO7vnm8e6=Q@mail.gmail.com>
 <44b3fb4b-4693-1639-c8c0-5e17296c196e@gmail.com>
 <CAMrTa2E9STK3G52mnQ9UsrUqi_bH4SMUzcE76PEGcxcLzGPVZA@mail.gmail.com>
In-Reply-To: <CAMrTa2E9STK3G52mnQ9UsrUqi_bH4SMUzcE76PEGcxcLzGPVZA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)
From: pierre-php@processus.org (Pierre)

Le 16/12/2021 à 05:01, Jordan LeDoux a écrit :
> This is not a use case I highlighted because it's one that would be
> difficult to support with this RFC. But as you say, it could be a good
> future expansion. In particular, putting a query builder object into core
> with some more advanced overloads built in may be the best way to
> accomplish this, particularly if it is built with the idea in mind that the
> entities themselves may also have overloads.
>
> I can certainly add it to the future scope of this RFC however.
>
> --
>
> RE: The operator keyword and operator implementations being non-callable.
>
> This was a limitation that I purposely placed on the operator keyword, as I
> didn't like the idea of allowing syntax of the style `$obj->{'+'}();` or
> `$obj->$op();` and I wanted developers to clearly understand that they
> shouldn't treat these as normal methods in the vast majority of
> circumstances. However, it seems this is one of the largest sticking points
> for those who would otherwise support the RFC. To that end, I'm considering
> removing that restriction on the `operator` keyword. If I were to do that,
> you'd no longer need to wrap the operator in a closure to call it, though
> the parser would still have problems with `$obj->+(...);`
>
> I suppose my question then would be, is this an acceptable compromise on
> the operator keyword? It removes one of the more annoying hurdles that
> Danack mentioned and that others have pointed out, but retains much of the
> benefits of the keyword that I expressed in my last email.
>
> Jordan

Hello,

I'm not an internals hacker nor someone who can vote, but here is my 
opinion about operator overloading: I don't like it. Nevertheless, if it 
has to be done, I'd like it to be less challenging for PHP newcomers or 
everyday developers.

An operator is not much more than a function shortcut, gmp examples 
prove that point quite well. I don't see why it is necessary to create a 
new syntax. It seems in the discussion that the magic method ship has 
sailed, but I'd much prefer it.

I don't see why a user wouldn't be able to call an operator 
method/function outside of the operator context. It has a signature: 
left operand and right operand are its parameters, and it has a return 
type. The engine internally will just call this function as userland 
code could do.

I think that adding a new syntax for it, and allowing weird function 
names which are the operator symbols will probably create some mind fuck 
in people's mind when reading the code. I like things being simple, and 
I'd love operator overloads to be simple functions, no more no less, not 
"a new thing". The more PHP syntax grows the more complex it is to learn 
and read.

Regarding the naming debate about operator names being different 
depending upon the context, I agree, but I don't care, if operators have 
a name in the engine, I'd prefer methods to carry the same name even if 
it yields a different name in the domain semantics of the object: if you 
are the low level operator function developer, you know what you are 
doing furthermore you can still comment code. If you're the end user, 
you will read the domain API documentation, not the code itself in many 
cases.

If the names are a problem, why not registering those using an attribute 
? If I remember well it was mentioned somewhere in the mail thread, it 
would provide a way to explicitly register any method, with any name, as 
being an operator implementation, sus userland could keep both syntax 
and use the one they wish (i.e. $newNumber = $number->add($otherNumber); 
or $newNumber = $number + $otherNumber. It's not insane to keep this 
possibility open, on the contrary, it'd leverage the fact that operator 
overloading in some context is just a shiny eye candy way of writing 
some domain function shortcut.

That's my opinion and I don't if it worth a penny, but in my mind, an 
operator is a function, and there's no reason that it'd be a different 
thing.

Regards,

--

Pierre