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 [email protected] 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




Thread (29 messages)

« previous php.internals (#71081) next »