Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124640
Feedback-ID: ifab94697:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-582-g5a02f8850-fm-20240719.002-g5a02f885
Precedence: bulk
MIME-Version: 1.0
Message-ID: <cdad94a3-fde5-4a4f-913c-f373cf8c33cc@app.fastmail.com>
In-Reply-To: <ab9ded6e-05be-43e7-bafb-f8a81eeba7e9@scriptfusion.com>
References: <ab9ded6e-05be-43e7-bafb-f8a81eeba7e9@scriptfusion.com>
Date: Sat, 27 Jul 2024 11:41:30 +0200
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Explicit callee defaults
Content-Type: multipart/alternative;
 boundary=afd720e7e05c497d883128f81714e9e5
From: rob@bottled.codes ("Rob Landers")

--afd720e7e05c497d883128f81714e9e5
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Fri, Jul 26, 2024, at 23:54, Bilge wrote:
> Hi Internals,
>=20
> New RFC idea just dropped. When writing a function, we can specify def=
aults for its parameters, and when calling a function we can leverage th=
ose defaults *implicitly* by not specifying those arguments or by "jumpi=
ng over" some of them using named parameters. However, we cannot *explic=
itly* use the defaults. But why would we want to?
>=20
> Sometimes we want to effectively *inherit* the defaults of a function =
we're essentially just proxying. One way to do that is copy and paste th=
e entire method signature, but if the defaults of the proxied method cha=
nge, we're now overriding them with our own, which is not what we wanted=
 to do. It is possible, in a roundabout way, to avoid specifying the opt=
ional parameters by filtering them out (as shown in the next example). T=
he final possibility is to use reflection and literally query the defaul=
t value for each optional parameter, which is the most awkward and verbo=
se way to inherit defaults.
>=20
> Let's use a concrete example for clarity.
>=20
> function query(string $sql, int $limit =3D PHP_INT_MAX, int $offset =3D=
 0);
>=20
>=20
>=20
> function myQuery(string $sql, ?int $limit =3D null, ?int $offset =3D n=
ull) {
>     query(...array_filter(func_get_args(), fn ($arg) =3D> $arg !=3D=3D=
 null));
> }
>=20
>=20
> In this way we are able to filter out the null arguments to inherit th=
e callee defaults, but this code is quite ugly. Moreover, it makes the (=
sometimes invalid) assumption that we're able to use `null` for all the =
optional arguments.
>=20
> In my new proposal for *explicit *callee defaults, it would be possibl=
e to use the `default` keyword to expressly use the default value of the=
 callee in that argument position. For example, the above implementation=
 for myQuery() could be simplified to the following.
>=20
>=20
>=20
> function myQuery(string $sql, ?int $limit =3D null, ?int $offset =3D n=
ull) {
>     query($sql, $limit ?? default, $offset ?? default);
> }
>=20
>=20
> Furthermore, it would also be possible to "jump over" optional paramet=
ers *without* using named parameters.
>=20
> json_decode($json, true, default, JSON_THROW_ON_ERROR);
>=20
> This proposal is built on the assumption that it is possible to specif=
y that PHP should only accept the `default` expression in method and fun=
ction call contexts. For example, it would not be valid to return `defau=
lt` from a function and substitute it that way; my proposal is to only p=
ermit `default` in literal function calling contexts. My knowledge of in=
ternals is insufficient (read: non-existent) to know whether or not this=
 restriction is possible to implement, but if it is, I think this is a g=
ood idea. What do you think?
>=20
>=20
>=20
> Cheers,
> Bilge
>=20
>=20

This seems like a case for code generation =E2=80=94 and an RFC that pro=
vides hooks for code generation would probably be better IMHO.

There are a couple of neat tools out there doing this and hooking into c=
omposer, like https://packagist.org/packages/olvlvl/composer-attribute-c=
ollector

There are many things that could benefit from this, such as DI container=
s, scanning for attributes, generating efficient serializers/deserialize=
rs, etc.=20

=E2=80=94 Rob
--afd720e7e05c497d883128f81714e9e5
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}
p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div><br></div>=
<div><br></div><div>On Fri, Jul 26, 2024, at 23:54, Bilge wrote:<br></di=
v><blockquote type=3D"cite" id=3D"qt" style=3D""><p>Hi Internals,<br></p=
><p>New RFC idea just dropped. When writing a function, we can
      specify defaults for its parameters, and when calling a function
      we can leverage those defaults <i>implicitly</i> by not
      specifying those arguments or by "jumping over" some of them using
      named parameters. However, we cannot <i>explicitly</i> use the
      defaults. But why would we want to?<br></p><p>Sometimes we want to=
 effectively <i>inherit</i> the defaults of
      a function we're essentially just proxying. One way to do that is
      copy and paste the entire method signature, but if the defaults of
      the proxied method change, we're now overriding them with our own,
      which is not what we wanted to do. It is possible, in a roundabout
      way, to avoid specifying the optional parameters by filtering them
      out (as shown in the next example). The final possibility is to
      use reflection and literally query the default value for each
      optional parameter, which is the most awkward and verbose way to
      inherit defaults.<br></p><p>Let's use a concrete example for clari=
ty.<br></p><p>function query(string $sql, int $limit =3D PHP_INT_MAX, in=
t $offset
      =3D 0);<br></p><p><br></p><div>function myQuery(string $sql, ?int =
$limit =3D null, ?int $offset =3D
      null) {<br></div><div>&nbsp;&nbsp;&nbsp; query(...array_filter(fun=
c_get_args(), fn ($arg) =3D&gt; $arg
      !=3D=3D null));<br></div><div>}<br></div><p><br></p><p>In this way=
 we are able to filter out the null arguments to
      inherit the callee defaults, but this code is quite ugly.
      Moreover, it makes the (sometimes invalid) assumption that we're
      able to use `null` for all the optional arguments.<br></p><p>In my=
 new proposal for <i>explicit </i>callee defaults, it
      would be possible to use the `default` keyword to expressly use
      the default value of the callee in that argument position. For
      example, the above implementation for myQuery() could be
      simplified to the following.<br></p><p><br></p><div>function myQue=
ry(string $sql, ?int $limit =3D null, ?int $offset =3D
      null) {<br></div><div>&nbsp;&nbsp;&nbsp; query($sql, $limit ?? def=
ault, $offset ?? default);<br></div><div>}<br></div><p><br></p><p>Furthe=
rmore, it would also be possible to "jump over" optional
      parameters <i>without</i> using named parameters.<br></p><p>json_d=
ecode($json, true, default, JSON_THROW_ON_ERROR);<br></p><p>This proposa=
l is built on the assumption that it is possible to
      specify that PHP should only accept the `default` expression in
      method and function call contexts. For example, it would not be
      valid to return `default` from a function and substitute it that
      way; my proposal is to only permit `default` in literal function
      calling contexts. My knowledge of internals is insufficient (read:
      non-existent) to know whether or not this restriction is possible
      to implement, but if it is, I think this is a good idea. What do
      you think?<br></p><p><br></p><div>Cheers,<br></div><div>Bilge<br><=
/div><p><br></p></blockquote><div><br></div><div>This seems like a case =
for code generation =E2=80=94 and an RFC that provides hooks for code ge=
neration would probably be better IMHO.<br></div><div><br></div><div>The=
re are a couple of neat tools out there doing this and hooking into comp=
oser, like&nbsp;<a href=3D"https://packagist.org/packages/olvlvl/compose=
r-attribute-collector">https://packagist.org/packages/olvlvl/composer-at=
tribute-collector</a><br></div><div><br></div><div>There are many things=
 that could benefit from this, such as DI containers, scanning for attri=
butes, generating efficient serializers/deserializers, etc.&nbsp;</div><=
div><br></div><div id=3D"sig121229152">=E2=80=94 Rob<br></div></body></h=
tml>
--afd720e7e05c497d883128f81714e9e5--