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 smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
