On Mon, Mar 13, 2023 at 12:28 PM Rowan Tommins <rowan.coll...@gmail.com> wrote: > > Hi all, > > On Sat, 11 Mar 2023 at 22:48, Robert Landers <landers.rob...@gmail.com> > wrote: > > > My "syntax sugar" implementation was that this: > > > > return $this->cache->get($command->getPhone(), $this->storeOtp($command, > > ...)); > > > > gets turned into this: > > > > return fn(...$x) => $this-cache->get($command->getPhone(), > > $this->storeOtp($command, ...$x)); > > > > There were a number of edge cases to solve, but I stopped > > implementation before I got there. > > > > > As someone who voted for the RFC a couple of years ago, and was > disappointed it didn't pass, I'm pleased to see more interest in this. > > It's worth noting that the previous implementation was reached after a lot > of different experiments, and there were a few requirements that guided it, > including (in no particular order, and I've probably forgotten something): > > * Placeholders need to be possible for any parameter, not just > left-to-right; e.g. it must be possible to apply the callback parameter to > array_filter (which is the 2nd param), producing a callable that accepts an > array to filter > * It should not be possible to partially apply a non-existent function; > this is one of the big advantages of first-class callable syntax over > existing string-based callables: https://3v4l.org/Vr9oq#v8.2.3 > * Errors from passing incorrect parameters should show as an error in the > actual call, not the wrapper; compare existing FCC behaviour with a manual > lambda: https://3v4l.org/Q2H2Z#v8.2.3 > * The generated callable should have correct parameter type and name > information visible in reflection (closely related to previous point) > * The relationship with named parameters and variadics needs to at least be > well-defined, even if it's "error with a possibility of expanding > functionality later" (this caused a lot of pain in some of the > implementation ideas) > * Repeated partial application (currying and similar) should ideally not > result in a whole stack of wrappers; that is $f = foo(42, ?, ?); $g = > $f(69, ?); should result in the same object as $g = foo(42, 69, ?); > > This is definitely one of those features where "the devil is in the > details", and a simpler implementation is possible, but may not be > desirable. > > Regards, > -- > Rowan Tommins > [IMSoP]
Hey Rowan, > This is definitely one of those features where "the devil is in the > details", and a simpler implementation is possible, but may not be > desirable. My approach was more of an iterative one. 1. Get left-right done so that $x = something($left, $right, ...); would be allowed, but not $x = something($left, ..., $right); This would bring some immediate benefits, as initially proposed. I'd also propose that variadic arguments wouldn't be allowed, thus array_map(..., $x); would be allowed, but not array_map($callback, ...); 2. Implement middle/variadic arguments I felt that this could be it's own RFC once the above is implemented. As you said, the devil is in the details... what does array_map($callback, ..., $right) do? Is the partial application variadic? These are things that I felt couldn't realistically be answered until we saw some real-life usage and feedback from (1) above. 3. Optimizations This would be when we flatten the callback chain OR maybe by now, the genius(es) working on the opcache would have already beaten everyone to the punch. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
