Re: Revisiting the "Named Arguments" RFC

From: Date: Sun, 12 Jan 2014 10:07:45 +0000
Subject: Re: Revisiting the "Named Arguments" RFC
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-71081@lists.php.net to get a copy of this message
Am So. Jan. 12 2014 10:52:46 schrieb Lester Caine: > I simply have to ask. What do you think this will actually give you productivity wise? > Personally I only see this as a totally backwards step which requires a lot more code in every > function call when if anything we should be simplifying that area. I know I'm not the only > person who does not like all this clutter and complication, and to be honest in my case it would be > yet another reason not to upgrade from my current PHP5.4 base ... which I'm still trying to > bring all the rest of my code up to … Personaly, I think that it makes API’s a -lot- easier. Let’s actually look at a real-life example: the Yii framework. To create a link via a PHP function, you have the following API: CHtml::link($name, $linkInformation); The second parameter is either an in-app route or a real url. If it is a string, it’s a real URL - if it’s an array, its a route, where $[0] contains the path, and everythign after are $_GET parameters. Now, let’s imagine how that may look like with named arguments: CHtml::link(name:$name, url:$url) CHtml::link(name:$name, path:$path, params:$array) See the huge difference? A possible declaration would be: public static function link($name, $url=null, $path, $params) However, that’d break backwards compatibility, right? Now, we had the idea of variadics: public static function link($name, …$linkInfo) Voila! We get the actual array back and minimal changes are required in the actual function - and we can still use „positional“ calling. The advantage is clearly the readability of code, and the learning curve that can be aquired with named arguments - things magically make more sense. Sure, you can memorize all the variable names. But imagine you go back to another project and see something like that: fnc_do_something($a, $b) In some case, you may not remember what that was - but if the arguments were named: fnc_do_something(file:$a, lookFor:$b) See? Now you know it’s supposed to be a file-searching function - and it may return either array or string…but maybe your mind kicked in by that time and you remember - making named arguments also a reminding help. … At least, that is what I think about the RFC and what it can be used for and with. > Saying I do not have to use it is simply not acceptable, since like E_STRICT, it will be used > to bring in yet more changes which have to be managed later. Huh? What does it matter to your scripts when E_STRICT is changed? o.O > Certainly PHP5.6 is not the venue for such a drastic change. Maybe right…maybe it’ll be in PHP6 after all. After all, I swear I saw PHP5.7 testing already O.o… Kind regards, Ingwie

« previous php.internals (#71081) next »