2021-06-29 0:54 GMT+02:00, Larry Garfield <la...@garfieldtech.com>: > On Mon, Jun 28, 2021, at 5:30 PM, Olle Härstedt wrote: > >> Mm. Assoc arrays are by now known to be not so good. I hope... > > There are millions of PHP sites build on anonymous arrays today. > >> OCaml is strictly evaluated, not lazy like Haskell. So the order might >> matter, dunno, I don't use this operator often. :) My point was mostly >> that it's very easy to add in OCaml - just one line. And as in >> Haskell, you can define operators in your modules. Similarly, in PHP >> it's easy to do super-dynamic stuff like "new $someclass", which is >> not remotely possible in FP (good or bad, depending on your religion). >> >> Adding a new pipe keyword is like the list() keyword, kind of. A bad >> idea, haha. But I think all stones can be turned, if this RFC now gets >> a no. :/ >> >> Would a slimmed down version have more support? How about removing the >> variadic operator, and let the user manually add the lambda for those >> cases? Could reduce the complexity while still covering maybe 80% of >> the use-cases? Same with removing support for named arguments. So '?' >> would only be a short-cut to get rid of boilerplate like `$strlen = >> fn($x) => strlen($x)`. > > I talked with Joe about this, and the answer is no. Most of the complexity > comes from the initial "this is a function call, oops no, it's a partial > call so we switch to doing that instead", which ends up interacting with the > engine in a lot of different places. Once you've done that, supporting one > placeholder or multiple, variadics or not, etc. is only a small incremental > increase in complexity. > >> > Overall, I really don't like the idea of special-casing pipes to change >> > what >> > symbol table gets looked up. >> >> Still wondering if this could be a per-file or per-library setting >> somehow, to opt-in into pipe behaviour when so desired. Or rather, to >> opt-in into this or that behaviour needed to do more idiomatic pipe. >> >> Here's one boilerplaty pipe: > > *snip* > > We're in the pipe thread here, not PFA. :-) And really, you're solving the > wrong problem. Pipes are trivial. They're only clunky because of PHP's > lack of decent callable syntax. PFA gives us that, but the engine makes the > implementation more complex than it seems like at first glance. > > Trying to come up with complex workarounds to make pipes pretty without > helping anything else is a fool's errand, especially when we have a working > PFA RFC that's about to end voting. (And right now is losing by a very slim > margin, but could pass if a few people change their minds.) > > Aside from something like Nikita's ...-only function reference RFC, which > only handles half the problem (it doesn't do anything to make multi-arg > functions work with pipes at all), any other solution is going to end up > reinventing PFA one way or another, or reinventing existing ugly user-space > libraries. one way or another > > I've not yet decided if I'm going to bring pipes to a vote if PFA doesn't > pass. I'm tempted to, but it would require rewriting all the RFC text back > to the uglier version without PFA, and yeah, it's not going to look as > pretty. And the main pushback a year ago when I first brought it up was > "PFA first, please, so the callable syntax isn't ugly." And... here we > are. > > --Larry Garfield
Is there no "pre-vote" process for RFCs? For example, letting the voting members *rate* different alternatives, in a ranking fashion, to see which one is most and least popular. Feels like a lot of work is getting wasted if something is voted down on a small margin. Olle -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
