Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115774
To: Jordan LeDoux <jordan.ledoux@gmail.com>,
 PHP internals <internals@lists.php.net>
References: <CAMrTa2HBv94ui0xGsqZwP=uL3AHQDMPAhaToo7m4F5Yh5QT64Q@mail.gmail.com>
 <2fd2d665-ca3a-4fa8-9196-6c8b1b2a3da0@www.fastmail.com>
 <CAMrTa2H9Y5PcyvQvgBieB_3nxGf9xHwOE-zijAGSBuwE7T6PqA@mail.gmail.com>
 <CAMrTa2HKaUS0yioyOE1+LD1mDx8hS=zJ0NhhNPd+1Yj-AjR6Eg@mail.gmail.com>
Message-ID: <2beca228-39ab-a2c6-41c2-136d88551205@processus.org>
Date: Mon, 23 Aug 2021 16:03:05 +0200
MIME-Version: 1.0
In-Reply-To: <CAMrTa2HKaUS0yioyOE1+LD1mDx8hS=zJ0NhhNPd+1Yj-AjR6Eg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Subject: Re: [PHP-DEV] [RFC] User Defined Operator Overloads
From: pierre-php@processus.org (Pierre)

Le 23/08/2021 à 15:37, Jordan LeDoux a écrit :
> Pierre and Dik,
>
> The thread you were replying to is older and doesn't reference the current
> RFC: https://wiki.php.net/rfc/user_defined_operator_overloads
>
> This is the current discussion thread for the RFC.
>
> In particular, I'd encourage reading about which operators are supported,
> the restrictions on the implementations, and the failure mode behavior.
>
> Pierre:
>> and hell, if "->" doesn't mean "access that object member" anymore, but
> "hey, the implementor could do anything at all instead", sky will fall upon
> us.
>
> I hate to break it to you, but __call and __get already do this, and aren't
> even a part of this RFC. I'd highly encourage you to read what operators
> are supported and how, because this RFC definitely does not suggest opening
> ALL operators to overloads. There are very deliberate omissions.

Yes, I'm well aware of that, but better stick with the devil you know :)

Anyway, I always thought that __set, __get __call and __invoke should 
have been banned a long time ago. I the hell the paved with good 
intentions and we cannot remove those since it would be a too big BC 
break. At least, we know those quite well and are used to it, but do it 
with *all* operators and code reading will become a real mess (you have 
to mentally switch from reading the line with an operator to grep some 
code in order to find the operator overload definition, whereas a nice 
method call makes everything clear and navigable in any IDE).

I read the whole RFC, I'm still not convinced it's a good thing to open 
the door to operator overloading, in my opinion, messy use case should 
probably be deprecated and replaced by semantic equivalent methods 
instead. Even thought I know for a long time that a few operators work 
with DateTime, it always mind-fuck me in some way.

That's a subjective opinion of course, and all your arguments remain 
legit and valid, you've probably thought the problem much more deeper 
than I did. At least, I give you that, it will give a rebirth of 
equals() and compareTo() declined RFCs, and that's something really 
positive in all that.

I'll give it a second read, I might not have seen all recent changes. 
Thanks for the quick answer.

Regards,

--

Pierre