Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124632
Content-Type: text/plain;
	charset=us-ascii
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\))
Subject: Re: [PHP-DEV] Explicit callee defaults
In-Reply-To: <8ac3f087-a739-4759-891c-3dd19260ef5e@gmx.de>
Date: Fri, 26 Jul 2024 20:04:25 -0400
Cc: Bilge <bilge@scriptfusion.com>,
 internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <34BF3A40-592C-41D7-8C35-5A9F3934E919@newclarity.net>
References: <ab9ded6e-05be-43e7-bafb-f8a81eeba7e9@scriptfusion.com>
 <8ac3f087-a739-4759-891c-3dd19260ef5e@gmx.de>
To: "Christoph M. Becker" <cmbecker69@gmx.de>
From: mike@newclarity.net (Mike Schinkel)

> On Jul 26, 2024, at 6:42 PM, Christoph M. Becker <cmbecker69@gmx.de> =
wrote:
>=20
> I have only skimmed your suggestion, but it sounds quite similar to
> <https://wiki.php.net/rfc/skipparams>.

I would really love to hear from some of those who voted "no" ~9 years =
why they did so, and if they still feel the same.

> On Jul 26, 2024, at 5:54 PM, Bilge <bilge@scriptfusion.com> wrote:
> When writing a function, we can specify defaults for its parameters, =
and when calling a function we can leverage those defaults implicitly by =
not specifying those arguments or by "jumping over" some of them using =
named parameters. However, we cannot explicitly 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 =
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.
>=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
> function myQuery(string $sql, ?int $limit =3D null, ?int $offset =3D =
null) {
>     query(...array_filter(func_get_args(), fn ($arg) =3D> $arg !=3D=3D =
null));
> }
>=20

Yes, I run into that issue all the time.  So much so that I adopted an =
"optional args" pattern which itself has many downsides but in my code =
it has had fewer downsides than doing it other ways.

So for your example I would write it like this (though I hate having to =
double-quote the names of the optional args):
function query(string $sql, array $args =3D []);

function myQuery(string $sql, array $args =3D []) {
    query($sql, $args);
}

myQuery("SELECT * FROM table;", ["offset" =3D> 100]));

This is very flexible and a pattern that served me well for 10+ years.=20=


But of course this has none of the type safety nor code-completion =
benefits of named parameters, which I would sorely like to have.


> 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.
>=20
> In my new proposal for explicit 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.
>=20
> function myQuery(string $sql, ?int $limit =3D null, ?int $offset =3D =
null) {
>     query($sql, $limit ?? default, $offset ?? default);
> }
>=20
> Furthermore, it would also be possible to "jump over" optional =
parameters without using named parameters.
>=20

To me, while nice I feel it is very much like only a quarter step in the =
right direction.

I do not meaning to highjack your thread; feel free to ignore this if =
you feel committed to pursing only your stated approach and are not =
interested in what I would like to see.  But I mention in hopes you and =
others see value in a more complete approach:

To begin, we can already currently do this (although I do not see many =
people doing it in PHP; fyi this approach is the norm for many Go =
programmers):

class QueryArgs {
   public function __construct(
     public ?int $limit =3D 100,
     public ?int $offset =3D 0,
   ){}
}

function myQuery(string $sql, QueryArgs $args =3D new QueryArgs()) {
   query($sql, $args);
}

myQuery("SELECT * FROM table;", new QueryArgs(offset:100));

I can only give my reasons for not doing it myself in PHP and speculate =
that others may have similar reasons and/or have never even considered =
it:

1.  Not having an easy and consistent way to declare the "args" class in =
the same file where the functions that use it are declared which keeps =
it out-of-sight and makes it harder to keep updated than it needs to be.

2. Having lots of visually annoying boilerplate that obscures a clear =
use-case.

What would be great IMO would be if PHP could elevate this concept to =
first class and add syntax and features to streamline and empower its =
use.  Imagine if we could instead:

1. Define an "args" type which would be based on a class like enum is =
based on a class:

args QueryArgs {
     public ?int $limit =3D 100;
     public ?int $offset =3D 0;
}

2. Declare a function to use those args, using your `default` keyword =
when they are optional:

function myQuery(string $sql, QueryArgs $args =3D default) {
   query($sql, $args);
}

3. And finally, allow a streamlined syntax to pass args:

myQuery("SELECT * FROM table;", {offset:100});

(I do not think we can or even should try to tackle the PSR-4 "every =
symbol in its own file" problem here, so I am going to leave that for =
other potential RFCs.)

-Mike