Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119716
MIME-Version: 1.0
References: <CAM0CcxhpMr_SstLCgcMfESTo4_H6yAPuBZb6B08KjbnKS97VfA@mail.gmail.com>
 <9975B833-EE24-4ED7-B28E-841B92988BA0@cschneid.com> <CAPzBOBPP8xy6S4nv2i8t1bgPj0hvFw4seBQ31QFSpA9aeAPyAA@mail.gmail.com>
 <CALKiJKoW0obHeG+53Yai25BHVDiscW6X7pn-uH+OLBDvvDQJ8Q@mail.gmail.com>
 <CAPzBOBMVnACDUrH=jCKPSNonzcv3Zm4J5yr5h1vVXHVOi872mA@mail.gmail.com>
 <1A2CE63B-ECCA-403D-83AC-B1E26279323C@gmail.com> <9a2140b4-97bb-4a9c-90c5-809274c83f75@app.fastmail.com>
 <88c4a63c-859b-94d5-e314-3399fb2c3fb0@gmail.com> <AM8P250MB017093F4BFE7C9E7B63AEF9CE2BE9@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
In-Reply-To: <AM8P250MB017093F4BFE7C9E7B63AEF9CE2BE9@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
Date: Wed, 15 Mar 2023 22:32:08 +0200
Message-ID: <CAM0CcxhDfG2M-KbT3A3po7CrWFm8QStZE+HUj6D_1HHNzYBNwg@mail.gmail.com>
To: Bob Weinand <bobwei9@hotmail.com>
Cc: Rowan Tommins <rowan.collins@gmail.com>, Garfield Larry <larry@garfieldtech.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a38ece05f6f63d00"
Subject: Re: [PHP-DEV] First-class callable partial application
From: zsidelnik@gmail.com (Eugene Sidelnyk)

--000000000000a38ece05f6f63d00
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 14, 2023 at 12:39=E2=80=AFPM Bob Weinand <bobwei9@hotmail.com> =
wrote:

>
> > Am 14.03.2023 um 10:16 schrieb Rowan Tommins <rowan.collins@gmail.com>:
> >
> > =EF=BB=BFOn 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 =3D htmlspecialchars(?, ENT_XML1);
> > $containsAt =3D str_contains(?, '@');
> > $priceFormatter =3D number_format(?, 2, ',', '.');
> > $addSigToFile =3D file_put_contents(?, $signature, FILE_APPEND);
> > $takeOwnership =3D chown(?, get_current_user());
> > $encode =3D json_encode(?, JSON_THROW_ON_ERROR |
> JSON_PRESERVE_ZERO_FRACTION);
> > $unserialize =3D unserialize(?, ['allowed_classes' =3D> false]);
> > $isLogger =3D is_subclass_of(?, LoggerInterface::class, false);
> >
> > I'm sure I could look through Laravel's documentation, or Symfony's, an=
d
> 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' =3D> $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.

--000000000000a38ece05f6f63d00--