Parameter skipping

  105123
April 6, 2019 21:15 php@duncanc.co.uk (Craig Duncan)
Hi all,

After starting to use https://wiki.php.net/rfc/json_throw_on_error in PHP
7.3 I've encountered the annoying issue of having to pass the $depth
parameter as 512 every time I want json_decode() to throw.

After doing this a few times I remembered the parameter skipping RFC that
Stas proposed a few years ago: https://wiki.php.net/rfc/skipparams

I've re-read the previous discussion and it seems to me there were two
common arguments against:
* Just design better APIs
* Named parameters would be better

Nobody has been able to crack named parameters (and it doesn't seem likely
anytime soon), and as we've seen from the JSON example above it's not
always as simple as having better APIs, so I wanted to see whether people
would be willing to support the *default* keyword for optional parameters
now.

Thanks,
Craig
  105124
April 6, 2019 22:45 morganbreden@gmail.com (Morgan Breden)
The problem I see with this approach is that a keyword for skipping
parameters
would really just be a stopgap solution until something like Named
Parameters
can be added.

Is it really appropriate to add a feature that only serves a temporary
purpose?

On Sat, Apr 6, 2019 at 5:15 PM Craig Duncan <php@duncanc.co.uk> wrote:

> Hi all, > > After starting to use https://wiki.php.net/rfc/json_throw_on_error in PHP > 7.3 I've encountered the annoying issue of having to pass the $depth > parameter as 512 every time I want json_decode() to throw. > > After doing this a few times I remembered the parameter skipping RFC that > Stas proposed a few years ago: https://wiki.php.net/rfc/skipparams > > I've re-read the previous discussion and it seems to me there were two > common arguments against: > * Just design better APIs > * Named parameters would be better > > Nobody has been able to crack named parameters (and it doesn't seem likely > anytime soon), and as we've seen from the JSON example above it's not > always as simple as having better APIs, so I wanted to see whether people > would be willing to support the *default* keyword for optional parameters > now. > > Thanks, > Craig >
  105125
April 6, 2019 22:58 robehickman@gmail.com (Robert Hickman)
Why not just wrap the function in another function?

On Sat, 6 Apr 2019 at 23:46, Morgan Breden <morganbreden@gmail.com> wrote:
> > The problem I see with this approach is that a keyword for skipping > parameters > would really just be a stopgap solution until something like Named > Parameters > can be added. > > Is it really appropriate to add a feature that only serves a temporary > purpose? > > On Sat, Apr 6, 2019 at 5:15 PM Craig Duncan <php@duncanc.co.uk> wrote: > > > Hi all, > > > > After starting to use https://wiki.php.net/rfc/json_throw_on_error in PHP > > 7.3 I've encountered the annoying issue of having to pass the $depth > > parameter as 512 every time I want json_decode() to throw. > > > > After doing this a few times I remembered the parameter skipping RFC that > > Stas proposed a few years ago: https://wiki.php.net/rfc/skipparams > > > > I've re-read the previous discussion and it seems to me there were two > > common arguments against: > > * Just design better APIs > > * Named parameters would be better > > > > Nobody has been able to crack named parameters (and it doesn't seem likely > > anytime soon), and as we've seen from the JSON example above it's not > > always as simple as having better APIs, so I wanted to see whether people > > would be willing to support the *default* keyword for optional parameters > > now. > > > > Thanks, > > Craig > >
  105126
April 6, 2019 23:12 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> The problem I see with this approach is that a keyword for skipping > parameters > would really just be a stopgap solution until something like Named > Parameters > can be added. > > Is it really appropriate to add a feature that only serves a temporary > purpose?
That was an argument in 2015. Today is 2019. We still have no named parameters. And we could have had this functionality for four years. But by all means, let's wait another 5 years before we can discuss again that we shouldn't implement functionality that we could have today because maybe in 5 years we could have a better one which nobody is working on and nobody has any idea how to accomplish. That sounds like a practical approach that served us well so far. -- Stas Malyshev smalyshev@gmail.com
  105127
April 7, 2019 05:00 me@jhdxr.com (=?utf-8?b?Q0hVIFpoYW93ZWk=?=)
> > The problem I see with this approach is that a keyword for skipping > > parameters would really just be a stopgap solution until something > > like Named Parameters can be added. > > > > Is it really appropriate to add a feature that only serves a temporary > > purpose? > > That was an argument in 2015. Today is 2019. We still have no named parameters. And we could have had this functionality for four years. But by all means, let's wait another 5 years before we can discuss again that we shouldn't implement functionality that we could have today because maybe in 5 years we could have a better one which nobody is working on and nobody has any idea how to accomplish. That sounds like a practical approach that served us well so far.
The [named parameters](https://wiki.php.net/rfc/named_params) was proposed in 2013. Does the problems which stopped us before still exist in 2019? Since we all agree named parameter should be a better solution, why not take a look at it first? Best regards, CHU Zhaowei
  105129
April 7, 2019 10:26 rowan.collins@gmail.com (Rowan Collins)
On 7 April 2019 06:00:53 BST, CHU Zhaowei <me@jhdxr.com> wrote:
>The [named parameters](https://wiki.php.net/rfc/named_params) was >proposed in 2013. Does the problems which stopped us before still exist >in 2019? Since we all agree named parameter should be a better >solution, why not take a look at it first?
I'm not 100% convinced named parameters are the solution to this problem, in all cases. In order to use named parameters, somebody needs to have declared what those names are, and made them a stable API. If they're automatically supported on existing functions, the author might not intend them to be used, or even realise they can, so not keep them stable (I tend to think of parameter names as local, not contractual). To use a default-skipping keyword, you need no extra promise than that already made, namely that the default for any parameter is a valid value for that parameter. Regards, -- Rowan Collins [IMSoP]
  105130
April 7, 2019 10:53 morganbreden@gmail.com (Morgan Breden)
>In order to use named parameters, somebody needs to have declared what those names are, and made them a stable API. If they're automatically
supported on existing functions, the author might not intend them to be used, or even realise they can, so not keep them stable (I tend to think of parameter names as local, not contractual). Wouldn't using the name of the variable that is already used for its function signature work perfectly fine for this? This is how IDEs already hint for function call completion. On Sun, Apr 7, 2019 at 6:26 AM Rowan Collins collins@gmail.com> wrote:
> On 7 April 2019 06:00:53 BST, CHU Zhaowei <me@jhdxr.com> wrote: > >The [named parameters](https://wiki.php.net/rfc/named_params) was > >proposed in 2013. Does the problems which stopped us before still exist > >in 2019? Since we all agree named parameter should be a better > >solution, why not take a look at it first? > > I'm not 100% convinced named parameters are the solution to this problem, > in all cases. > > In order to use named parameters, somebody needs to have declared what > those names are, and made them a stable API. If they're automatically > supported on existing functions, the author might not intend them to be > used, or even realise they can, so not keep them stable (I tend to think of > parameter names as local, not contractual). > > To use a default-skipping keyword, you need no extra promise than that > already made, namely that the default for any parameter is a valid value > for that parameter. > > Regards, > > -- > Rowan Collins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  105131
April 7, 2019 12:33 rowan.collins@gmail.com (Rowan Collins)
On 07/04/2019 11:53, Morgan Breden wrote:
> >In order to use named parameters, somebody needs to have declared > what those names are, and made them a stable API. If they're > automatically supported on existing functions, the author might not > intend them to be used, or even realise they can, so not keep them > stable (I tend to think of parameter names as local, not contractual). > > Wouldn't using the name of the variable that is already used for its > function signature work perfectly fine for this? > This is how IDEs already hint for function call completion.
Yes, that's what I meant by "automatically supported on existing functions". The problem I was highlighting is that right now, I can write this in version 1.0.0 of a library: function foo($id) {     $blobId = $id;     doSomething($blobId); } And change it to this in version 1.0.1, without violating SemVer: function foo($blobId) {     doSomething($blobId); } The name of the parameter is an implementation detail, not a contract. If named parameters are automatic, that suddenly becomes a breaking change, and either every library author recognises that and avoids such changes, or every library user has to check documentation to see if it's safe to use named parameters. Worse, as highlighted in the 2013 RFC, parameter names aren't checked when over-riding a method, like this: interface Fooable { public function foo(int $id); } class Blob implements Fooable { public function foo(int $blobId) { ... } } So either the first version of PHP to support named parameters would require library authors to change any such code, or again the library user has to check if it's safe to use named parameters. The alternative is to make named parameters opt-in on the part of the function author, using extra syntax in the function declaration. I think that's a better approach, but probably means an even longer wait until libraries introduce it. So realistically, even if named arguments were added right now, they couldn't reliably be used to skip over default parameters in existing functions. None of this is a problem with a simple "default" keyword, which would work reliably with all existing function signatures where a default is defined, and require no change in code or practice on the part of library authors, so can be introduced right now, and used straight away. Regards, -- Rowan Collins [IMSoP]