On Tue, Mar 14, 2023 at 12:39 PM Bob Weinand <bobw...@hotmail.com> wrote:
> > > Am 14.03.2023 um 10:16 schrieb Rowan Tommins <rowan.coll...@gmail.com>: > > > > On 13/03/2023 20:44, Larry Garfield wrote: > >> As has been discussed numerous times, all of the most used array > functions need to be redesigned to work with iterables, and in many cases > make more sense. That would be a natural time to also revisit parameter > order to fit with whatever partial application syntax was in use. > > > > > > It's not just the array functions, though, it's every single function > built into PHP, and an even longer list of userland library and framework > functions; and there will always be competing reasons for preferring one > signature over another. What attracts me about features like PFA is > precisely that they let you work in new ways *without* having to rewrite > all of that. > > > > Some more examples of placeholder-first application, from a quick skim > through the documentation: > > > > $escape = htmlspecialchars(?, ENT_XML1); > > $containsAt = str_contains(?, '@'); > > $priceFormatter = number_format(?, 2, ',', '.'); > > $addSigToFile = file_put_contents(?, $signature, FILE_APPEND); > > $takeOwnership = chown(?, get_current_user()); > > $encode = json_encode(?, JSON_THROW_ON_ERROR | > JSON_PRESERVE_ZERO_FRACTION); > > $unserialize = unserialize(?, ['allowed_classes' => false]); > > $isLogger = is_subclass_of(?, LoggerInterface::class, false); > > > > I'm sure I could look through Laravel's documentation, or Symfony's, and > find examples there too. > > > > Regards, > > > > -- > > Rowan Tommins > > [IMSoP] > > Hey Rowan, > > do we actually need *positional* partial application, after a ... token? > > Would it not be enough, to simply forbid positional arguments after a ... > and just allow named arguments? These already have well defined position > independent semantics. > > There may be some desire for a single argument placeholder later on, but > this can be introduced later, separately. > > Bob Personally, I agree with Robert. It seems logical to have ... only at the end of arguments list. Anything else can be bound by positional and named arguments. For instance: ``` str_contains(?, '@'); // do you remember if arg 2 is a needle or a haystack? str_contains(needle: '@', ...); // far more readable when explicitly specified explode(?, $str) // do you remember that argument 2 is actual string being exploded (not a delimiter)? explode(string: $str, ...) // delimiter will be provided to the closure ``` On the first stage, maybe it's better to have only positional arguments available without a possibility to provide named ones. I guess this will reveal a lot of pitfalls to consider. For instance, if some third-party library function signature has a signature with a variadic parameter `foo($bar, $baz, ...$x)`. We make a closure for it like this `foo(baz: $b, ...)` and it works fine. Later on authors of a library rename $baz into $tar and it gets unnoticed. Hence, the new signature is `foo($bar, $tar, ...$x)`. How would `foo(baz: $b, ...)` work? Will it put ['baz' => $b] into an $x argument? Firstly, it would make sense to only allow simple use cases of PFA. E.g. only positional parameters. Hence, it won't be possible to use PFA if we want to bind non-prefix parameters. Though, well-designed functions, which declare parameters starting from the most generic unto most specific, will perfectly fit into PFA.
