# Parameter skipping - Thread: https://externals.io/message/105123 - Original archive: https://news-web.php.net/php.internals/105123 - Started by Craig Duncan on 2019-04-06T21:15:39+00:00 - Messages: 9 - RFC: JSON_THROW_ON_ERROR (Implemented (PHP 7.3)) — https://externals.io/rfc/json_throw_on_error.md - RFC: Skipping optional parameters (Declined) — https://externals.io/rfc/skipparams.md - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #105123 — Craig Duncan — 2019-04-06T21:15:39+00:00 URL: https://externals.io/message/105123#105123 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 — Morgan Breden — 2019-04-06T22:45:38+00:00 URL: https://externals.io/message/105123#105124 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 --- ## #105125 — Robert Hickman — 2019-04-06T22:58:06+00:00 URL: https://externals.io/message/105123#105125 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? > > > > > […] --- ## #105126 — Stanislav Malyshev — 2019-04-06T23:12:09+00:00 URL: https://externals.io/message/105123#105126 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 — me@jhdxr.com — 2019-04-07T05:00:53+00:00 URL: https://externals.io/message/105123#105127 > > […] > > 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 --- ## #105128 — Gabriel O — 2019-04-07T10:21:35+00:00 URL: https://externals.io/message/105123#105128 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 > wrote: > > > […] --- ## #105129 — Rowan Collins — 2019-04-07T10:26:04+00:00 URL: https://externals.io/message/105123#105129 >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 — Morgan Breden — 2019-04-07T10:53:56+00:00 URL: https://externals.io/message/105123#105130 >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 wrote: > > > […] > > 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] --- ## #105131 — Rowan Collins — 2019-04-07T12:33:58+00:00 URL: https://externals.io/message/105123#105131 > > […] > 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]