On Tue, Mar 22, 2022, at 12:59 PM, Sara Golemon wrote: > On Tue, Mar 22, 2022 at 10:31 AM Christian Schneider <cschn...@cschneid.com> > wrote: > >> Am 22.03.2022 um 16:14 schrieb Sara Golemon <poll...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
