Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71081
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 74.125.83.52 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
In-Reply-To: <52D265EE.3010608@lsces.co.uk>
Date: Sun, 12 Jan 2014 11:07:45 +0100
Cc: internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <6787ED3A-9875-4EC6-9137-F59F49E76428@googlemail.com>
References: <581A185E-0F00-4B49-AA87-859D75E63BA2@googlemail.com> <CAJ26g5Q40RH9c80r0=7wQNoBnciNi-=n_VdAaDMfqbqbwKfpJw@mail.gmail.com> <52D265EE.3010608@lsces.co.uk>
To: Lester Caine <lester@lsces.co.uk>
Subject: Re: [PHP-DEV] Revisiting the "Named Arguments" RFC
From: ingwie2000@googlemail.com (Kevin Ingwersen)

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 =85
Personaly, I think that it makes API=92s a -lot- easier. Let=92s =
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=92s a real URL - if it=92s an array, its a route, where $[0] =
contains the path, and everythign after are $_GET parameters. Now, let=92s=
 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=3Dnull, $path, $params)

However, that=92d break backwards compatibility, right? Now, we had the =
idea of variadics:

	public static function link($name, =85$linkInfo)

Voila! We get the actual array back and minimal changes are required in =
the actual function - and we can still use =84positional=93 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=92s supposed to be a file-searching function - and =
it may return either array or string=85but maybe your mind kicked in by =
that time and you remember - making named arguments also a reminding =
help.

=85 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=85maybe it=92ll be in PHP6 after all. After all, I swear I =
saw PHP5.7 testing already O.o=85

Kind regards, Ingwie