Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117402
User-Agent: Cyrus-JMAP/3.5.0-alpha0-4907-g25ce6f34a9-fm-20220311.001-g25ce6f34
Mime-Version: 1.0
Message-ID: <fbc24c36-92c4-4602-9566-e1336c6b44a1@www.fastmail.com>
In-Reply-To: 
 <CAESVnVoX6s4cWD6mWNpT+90L+8n07+VMapWccbFFASP_RT3aXQ@mail.gmail.com>
References: 
 <CAESVnVq80gzujeb_DsfH9hU5Q+YVQcAYF+siLZSiQOC2cxDBqw@mail.gmail.com>
 <1289b56c-e766-4889-bbb2-06abb4e63a6d@www.fastmail.com>
 <CABdc3WrSUjPSA+XqHv1bGi_1kvr6ampfg4ggS9tZwgRSFpvG=A@mail.gmail.com>
 <CAPzBOBMQSEzMeGvS=dJfbPKsYT7JhF5O5hL7WEs-ivE3kgsJ3A@mail.gmail.com>
 <CAESVnVo4aCeaQe5Vsi858G9X02nkh0qsX73K-XQJ5M3qvrFNrg@mail.gmail.com>
 <3496914D-AF9A-48FD-B37C-DCA54CB32AFA@cschneid.com>
 <CAESVnVoX6s4cWD6mWNpT+90L+8n07+VMapWccbFFASP_RT3aXQ@mail.gmail.com>
Date: Tue, 22 Mar 2022 19:21:25 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] Discussion: String streams
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Mar 22, 2022, at 12:59 PM, Sara Golemon wrote:
> On Tue, Mar 22, 2022 at 10:31 AM Christian Schneider <cschneid@cschneid.com>
> wrote:
>
>> Am 22.03.2022 um 16:14 schrieb Sara Golemon <pollita@php.net>:
>> > So while I said I wanted to avoid the firestorm suggesting userspace
>> > overloading would bring, maybe that's the question to ask:
>> >
>> > Who's just a hard-nope on userspace operator overloading?  If your
>> reasons
>> > go beyond foot-gun (and that is a valid reason), could you share what
>> those
>> > reasons are?
>>
>>
>> An obvious one could be complexity.
>>
>> In the discussion about warning in conjunction with type juggling it was
>> mentioned that this leads to increased complexity in the PHP core. While my
>> knowledge of the engine is too superficial to really know I'd assume that
>> generic operator overload could lead to quite some additional complexity
>> and/or overhead.
>>
>>
> I'm not terribly worried about complexity since operator overloading
> *already* exists in the engine.  The only thing we don't have is a little
> bit of glue to map these out to method calls.
>
> This would be best served by actually writing up an implementation, which I
> may do yet, but at the moment, I'm just gathering opinions.
>
> -Sara

Are we talking about *arbitrary* user-space operator overloading?  Because a very specific, non-arbitrary, well-designed operator overloading RFC was just rejected.  I don't know that anything has changed that would result in a different result for an even-broader (more foot-gunny) RFC.

Personally I'd settle for a bind operator, comparison operators, an some built-ins to use those for a new stream API bootstrap.  That would already be huge, but the voters seem not favorable. :-(

Side note: I was asked elsewhere if bind was like pipe, since they look alike.  Yes, bind is simply a "fancy pipe", essentially, for some contextually-relevant definition of "fancy".  We should still add the non-fancy pipe as well while we're at it, but that's a separate RFC. :-)

--Larry Garfield