[RFC] Parameter skipping, take 3

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.

On 05/01/2015 22:35, Andrea Faulds wrote:

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.

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.