Re: Discussion: String streams
| From: | Larry Garfield | Date: | Wed, 23 Mar 2022 00:21:25 +0000 |
| Subject: | Re: Discussion: String streams | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-117402@lists.php.net to get a copy of this message | ||
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