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]
