Parameter skipping

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

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?

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

Why not just wrap the function in another function?

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?

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

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

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 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

I mean it’s easier than named parameters. I guess I replied to wrong thread, but wanted to contrast “default” with JSON_DEFAULT_DEPTH. Accepting string in integer parameter just creates mores issues. And please don’t use name conflicts as argument for not adding something. It’s absurd to stop adding anything in minor releases because name can conflict with userland, especially in case name is prefixed like here.

Hi Gabriel, do you mean a constant for every parameter's default value? I'm not sure how that's easier, and it's technically worse for BC as default is already a keyword but your new global constants could clash with userland ones.

Wouldn't better (and still easy and bc) solution be to just have constant
holding default value?

On 6 April 2019 11:16:02 PM Craig Duncan <php@duncanc.co.uk mailto:php@duncanc.co.uk> wrote:

Hi all,

After starting to use https://wiki.php.net/rfc/json_throw_on_error 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 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

The named parameters 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]

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 rowan.collins@gmail.com
wrote:

The named parameters 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]

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]