On Thu, May 20, 2021 at 8:38 PM Larry Garfield <la...@garfieldtech.com> wrote:
> > There's been a lot of rapid iteration, experimentation, and rejection. > The most recent alternatives are this one from Levi: > > https://gist.github.com/morrisonlevi/f7cf949c02f5b9653048e9c52dd3cbfd > > And this one from me: > > https://gist.github.com/Crell/ead27e7319e41ba98b166aba89fcd7e8 > > Intuitively, I think I prefer your algorithm as these are written up. Levi's allows for named placeholders which I'm sure for some users is a big draw. But I think what you're proposing is cleaner and will be better understood. It resolves a lot of the concerns which came up in the PFA thread, striking a reasonable balance between benefit and simplicity. Either way suggests compatibility with Nikita's proposal, assuming use of the spread operator as the implemented syntax. For this RFC in isolation, though, it does loosely concern me as a user the proposed syntax looks more like a function call. I won't bog anyone down arguing the syntax, it's a minor detail for users to get used to in the grand scheme of things and I'd definitely rather it was possible to build the more powerful PFA on top than bin that off, or end up with a convoluted PHP providing competing ways of doing the same thing. > * Named arguments make things more complicated. One of the questions is > whether named placeholders should be supported or not. And if they are, > does that mean you can effectively reorder the arguments in the partial > application, and what does that mean for usability. It gets complicated > and scope-creepy fast. > I do share the concern about named arguments and it's one of the reasons I prefer your proposal. I think scaling back the scope a little bit is exactly what's needed right now. > While I agree Nikita's RFC here would be an improvement over 8.0, I don't > think throwing in the towel on PFA yet is a good idea. It's a much more > robust and powerful approach that still gets us the "first class callable" > syntax we all want (at least I assume we all do), and lots of additional > power to boot. I'd rather see us try to drive PFA home to completion. If > that proves impossible by early July, then this RFC would still get us > something this cycle, as long as the syntax is still compatible with PFA. > I think this is very sensible, I can only really say I'd rather have Nikita's proposal land in 8.1 and PFAs in 9.0 done right than have PFAs in 8.1 but in a way which is confusing, ambiguous or problematic for users, or not covering reasonable expected use cases.
