# [RFC] Parameter skipping, take 3

- Thread: https://externals.io/message/80201
- Original archive: https://news-web.php.net/php.internals/80201
- Started by Stanislav Malyshev on 2015-01-05T22:02:56+00:00
- Messages: 9
- 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

---

## #80201 — Stanislav Malyshev — 2015-01-05T22:02:56+00:00

URL: https://externals.io/message/80201#80201

Hi!

As I've got some questions on the topic, I'd like to revive and soon put
to vote the parameter skipping RFC: https://wiki.php.net/rfc/skipparams

For those who doesn't remember, quick reminder - it is about an ability
to skip parameters in function calls so they'd take default value, like
this:
function foo($a, $b = true, $c = "abc") { ... }
foo($x, default, $y); // $b gets to be true here

In the last discussion I had a lot of "objections" to the tune of "we'd
rather have named parameters". I like the idea of named parameters too,
but this one does not contradict it - rather, it compliments it, and a
lot of the extensions cleanup done in this patch also serves as a base
for possible implementation of named params, if it happens (more on that
in the RFC itself).

The pull is at: https://github.com/php/php-src/pull/981
The patch has been reworked to work with PHP 7 engine changes, it is not
perfect yet but in workable condition, and at this point I'd like to
have a decision if we want to continue with it before I invest more time
into covering the remaining corners.

Note that the RFC has been changed in some details (e.g. variadics
handling, but there's more) since the last time it was discussed, due to
the changes in phpng, so I recommend re-reading the RFC even if you were
familiar with it before.
-- 
Stas Malyshev
smalyshev@gmail.com

---

## #80204 — Andrea Faulds — 2015-01-05T22:15:11+00:00

URL: https://externals.io/message/80201#80204 · In reply to: #80201

Hi Stas,

> 
> 
> For those who doesn't remember, quick reminder - it is about an ability
> to skip parameters in function calls so they'd take default value, like
> this:
> function foo($a, $b = true, $c = "abc") { ... }
> foo($x, default, $y); // $b gets to be true here
> 
> In the last discussion I had a lot of "objections" to the tune of "we'd
> rather have named parameters". I like the idea of named parameters too,
> but this one does not contradict it - rather, it compliments it, and a
> lot of the extensions cleanup done in this patch also serves as a base
> for possible implementation of named params, if it happens (more on that
> in the RFC itself).

Yes, they complement one another. Both exist because of horrible APIs. But I don’t think we should encourage horrible APIs.

I don’t want to end up with the Windows API, except in PHP style:

CreateWindowEx($foo, default, default, $bar, 0, 0, 100, 100, default, default, default, default);

For well-designed functions, there is no need to skip parameters, either with a default keyword or with named parameters.

So it’s a firm -1 from me. The solution to horrid APIs isn’t to add kludges to the language that make them slightly less painful. The solution is to fix them, or add new APIs, that are well designed.

Thanks!

--
Andrea Faulds
http://ajf.me/

---

## #80205 — Stanislav Malyshev — 2015-01-05T22:24:58+00:00

URL: https://externals.io/message/80201#80205 · In reply to: #80204

Hi!

> Yes, they complement one another. Both exist because of horrible
> APIs. But I don’t think we should encourage horrible APIs.

You can create horrible APIs with this, but you can also create them
without this. This doesn't make it any more likely, it just makes
working with optional parameters easier.

> For well-designed functions, there is no need to skip parameters,
> either with a default keyword or with named parameters.

I disagree with that and in general I disagree with the stance "I don't
need this so the language does not need that". We can and should have a
wider look than personal needs and preferences. There are many cases
where optional parameters have their place, and making them more
convenient is a good thing. As a witness to that, most of the languages
with this syntax model (I'm not talking about the likes of Lisp of
course) do allow optional parameters, and making it easy to work with
them is a very frequently requested (and implemented) feature. You can,
of course, say these all people are wrong and their code is horrible,
but this is the reality of what people want and what they use. They'll
do it whether you like it or not, but with this RFC it would be less
painful. For me, it is a clear win.

-- 
Stas Malyshev
smalyshev@gmail.com

---

## #80206 — Andrea Faulds — 2015-01-05T22:35:20+00:00

URL: https://externals.io/message/80201#80206 · In reply to: #80205

Hi Stas,

> 
> 
> Hi!
> 
> > […]
> 
> You can create horrible APIs with this, but you can also create them
> without this. This doesn't make it any more likely, it just makes
> working with optional parameters easier.

Sure, but things like this make such APIs easier to work with. That’s not a good thing.

> > […]
> 
> I disagree with that and in general I disagree with the stance "I don't
> need this so the language does not need that”.

It’s not that I don’t need this… there are some horrible APIs I’ve used which would be slightly (but only slightly) more pleasant to use with this feature. But I don’t think we should add features to the language to work around poor API design. We should get better APIs instead.

> We can and should have a
> wider look than personal needs and preferences. There are many cases
> where optional parameters have their place, and making them more
> convenient is a good thing.

There are places where optional parameters are good. I never said they were bad. This RFC doesn’t help with optional parameters, it helps with excessive numbers of them, or optional parameters with weird default values. I don’t think that it is necessary to have parameter skipping for a well-designed API. If the default values are obvious and intuitive, as they should be, you don’t need “default”. If there is not an excessive number of parameters, you don’t need “default”.

If your function takes so many arguments that you need “default”, you should probably reconsider your function’s signature. If someone else’s function does so, you should probably either fix it for them or write a wrapper function, so people trying to read and maintain your code don’t gradually go insane.

> As a witness to that, most of the languages
> with this syntax model (I'm not talking about the likes of Lisp of
> course) do allow optional parameters, and making it easy to work with
> them is a very frequently requested (and implemented) feature.

Well, some of the languages. Others have decided that named parameters aren’t a good idea.

> You can,
> of course, say these all people are wrong and their code is horrible,
> but this is the reality of what people want and what they use. They'll
> do it whether you like it or not, but with this RFC it would be less
> painful. For me, it is a clear win.

I’m not sure if this RFC actually would make such functions that much less painful. For functions with a lot of default parameters, telling them apart is key. Seeing “NULL, FALSE, FALSE, 0, NULL” may orient the user better when scanning a parameter list than “default, default, default, default, default” would.

Thanks!
--
Andrea Faulds
http://ajf.me/

---

## #80207 — Stanislav Malyshev — 2015-01-05T22:51:54+00:00

URL: https://externals.io/message/80201#80207 · In reply to: #80206

Hi!

> Sure, but things like this make such APIs easier to work with. That’s
> not a good thing.

For me, it is. Your stance is "if it's not ideal (in my opinion) design,
we should not do anything to make it better". I think it's wrong - there
are many opinions about what ideal design is, and yours has no inherent
advantage over others. Removing the existing pain is always good for me,
and telling people "rewrite all your code or live with the pain forever"
is not a good practical stance. It may feel very purist and satisfying -
"here we showed these horrible people how to do things right!" - but
practically it is next to useless. PHP has always been a practical and
not theory-purist language, and this IMO falls directly in this category.

> There are places where optional parameters are good. I never said
> they were bad. This RFC doesn’t help with optional parameters, it
> helps with excessive numbers of them, or optional parameters with

"Excessive" is a matter of opinion. If you have more than one of them,
this RFC is helpful.

> Well, some of the languages. Others have decided that named
> parameters aren’t a good idea.

I don't think the majority of PHP users here on your side:
http://programmers.stackexchange.com/questions/27564/what-features-would-you-like-to-have-in-php
Neither probably would be a majority of Python users. Or Ruby users. Of
course, you can say all these people are horrible programmers who know
nothing about designing APIs, but I'm afraid if you exclude all these
from consideration when you design language features I'll get pretty
lonely.

> them apart is key. Seeing “NULL, FALSE, FALSE, 0, NULL” may orient
> the user better when scanning a parameter list than “default,
> default, default, default, default” would.

Nobody would use "default, default, default, default" because that's
meaningless, you could just not put them in. $foo, default, $bar would
be much more frequent case, and that's what it is for. You can, of
course, get it to absurd lengths, but so can be done to any feature.

-- 
Stas Malyshev
smalyshev@gmail.com

---

## #80210 — Marcio Almada — 2015-01-05T23:14:06+00:00

URL: https://externals.io/message/80201#80210 · In reply to: #80207

Hi,

Stanislav, great RFC. A huge part of core PHP API would benefit of
parameter skipping.

Andrea Faulds,

> It’s not that I don’t need this… there are some horrible APIs I’ve used
which would be slightly (but only slightly) more pleasant to use with this
feature. But I don’t think we should add features to the language to work
around poor API design. We should get better APIs instead.

Not sure how this RFC rant is helpful since it's based on completely unreal
alternatives. This "We should get better APIs instead" suggestion, in
practice, means a ton of BC breaks that will never happen on PHP global
functions for obvious reasons.


2015-01-05 19:51 GMT-03:00 Stanislav Malyshev <smalyshev@gmail.com>:

> Hi!
>
> > […]
>
> For me, it is. Your stance is "if it's not ideal (in my opinion) design,
> we should not do anything to make it better". I think it's wrong - there
> are many opinions about what ideal design is, and yours has no inherent
> advantage over others. Removing the existing pain is always good for me,
> and telling people "rewrite all your code or live with the pain forever"
> is not a good practical stance. It may feel very purist and satisfying -
> "here we showed these horrible people how to do things right!" - but
> practically it is next to useless. PHP has always been a practical and
> not theory-purist language, and this IMO falls directly in this category.
>
> > […]
>
> "Excessive" is a matter of opinion. If you have more than one of them,
> this RFC is helpful.
>
> > […]
>
> I don't think the majority of PHP users here on your side:
>
> http://programmers.stackexchange.com/questions/27564/what-features-would-you-like-to-have-in-php
> Neither probably would be a majority of Python users. Or Ruby users. Of
> course, you can say all these people are horrible programmers who know
> nothing about designing APIs, but I'm afraid if you exclude all these
> from consideration when you design language features I'll get pretty
> lonely.
>
> > […]
>
> Nobody would use "default, default, default, default" because that's
> meaningless, you could just not put them in. $foo, default, $bar would
> be much more frequent case, and that's what it is for. You can, of
> course, get it to absurd lengths, but so can be done to any feature.
>
> --
> Stas Malyshev
> smalyshev@gmail.com

---

## #80211 — Andrea Faulds — 2015-01-05T23:17:22+00:00

URL: https://externals.io/message/80201#80211 · In reply to: #80210

Hi Marcio,

> 
> 
> Not sure how this RFC rant is helpful since it's based on completely unreal
> alternatives. This "We should get better APIs instead" suggestion, in
> practice, means a ton of BC breaks that will never happen on PHP global
> functions for obvious reasons.

I’m not saying change existing APIs. I’m saying add new, parallel ones. We’ve done this before, we can do it again. It doesn’t break BC.
--
Andrea Faulds
http://ajf.me/

---

## #80214 — Marcio Almada — 2015-01-05T23:26:09+00:00

URL: https://externals.io/message/80201#80214 · In reply to: #80211

> I’m not saying change existing APIs. I’m saying add new, parallel ones.
We’ve done this before, we can do it again. It doesn’t break BC.

Makes sense to have new better overlapping APIs while old ones are slowly
deprecated (which is still a (delayed) BC break). Thanks for clarifying
this, anyway.

But I still disagree when you say that parameter skipping would
instantly "encourage
horrible APIs". That's a huge stretch, IMMO, unless you have any real case
to support such statement.


2015-01-05 20:17 GMT-03:00 Andrea Faulds <ajf@ajf.me>:

> Hi Marcio,
>
> > […]
> unreal
> > […]
>
> I’m not saying change existing APIs. I’m saying add new, parallel ones.
> We’ve done this before, we can do it again. It doesn’t break BC.
> --
> Andrea Faulds
> http://ajf.me/

---

## #80241 — Rowan Collins — 2015-01-06T19:53:21+00:00

URL: https://externals.io/message/80201#80241 · In reply to: #80206

> If the default values are obvious and intuitive, as they should be, you don’t need “default”.

It's not always a case of not knowing what the default values are; 
sometimes it's a case of not knowing - and not wanting to worry about - 
what they might be in the future.

For instance, you might have an integer parameter representing some kind 
of cost-benefit tradeoff, with a "best practice" value as default, which 
happened to be the second of 3 well-defined parameters. To specify the 
third parameter, you need some way of saying "I'll accept the best 
practice for the second parameter, thanks".

There are a few options we can consider:
- You just hard-code the current documented value, leaving a comment 
that you have no idea what it means, or whether it might change. Clearly 
not optimal.
- The library allows some special-case value, such as NULL, to be 
passed. Not particularly readable, because it's not clear what `NULL` 
means in this context, or whether you've just messed up and it will be 
coerced to int(0). On the other hand, allows calling with a variable set 
to `NULL` (or other magic value) to select the default behaviour at run-time.
- The library defines a constant containing the default value, such as 
DEFAULT_FOO_COST. More readable, but relies on the library author having 
a good naming convention so that you don't have to keep going to the 
manual to find it.
- The proposed "default" keyword. More explicit than NULL, supported 
out-the-box without any effort on the part of the library author, lets 
you get on with your job. On the other hand, doesn't address the case 
where you want to select the default at run-time, e.g. foo('bar', 
$_GET['cost'] ?? default, 'baz') doesn't work; this is however true of 
existing optional parameters, it's just that they can only come at the 
end of the list.


> I’m not sure if this RFC actually would make such functions that much less painful. For functions with a lot of default parameters, telling them apart is key. Seeing “NULL, FALSE, FALSE, 0, NULL” may orient the user better when scanning a parameter list than “default, default, default, default, default” would.

A list of all defaults is clearly a straw man, since it would be a daft 
use of this feature. However, "10, null, default, 0" is clearer in its 
intent than "10, null, false, 0" - the 1st, 2nd and 4th parameters have 
been specifically chosen by the programmer, while the 3rd is left to the 
implementation to choose.


Named parameters do seem to offer a solution to a lot of the same use 
cases, but they have their drawbacks too - for instance, currently, 
parameter names are implementation details private to the function, and 
a straight implementation of named parameters would make them public 
overnight. However, as Stas says, the two mechanisms can coexist and 
complement each other, and if we get both it can be left to a matter of 
personal taste or style guides.

-- 
Rowan Collins
[IMSoP]