Hi Stas, > On 5 Jan 2015, at 22:24, Stanislav Malyshev <smalys...@gmail.com> wrote: > > 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.
Sure, but things like this make such APIs easier to work with. That’s not a good thing. >> 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”. 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
