Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:21518
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <7.0.0.16.2.20060113084431.07b461e8@zend.com>
Date: Fri, 13 Jan 2006 08:47:56 -0800
To: Lukas Smith <lsmith@php.net>
Cc: internals@lists.php.net
In-Reply-To: <43C75FEE.7040908@php.net>
References: <F285517D-8EEB-40FB-A069-30E7B315E560@intuitivefuture.com>
	<D5.B6.19414.18252C34@pb1.pair.com>
	<43C67431.9090003@prohost.org>
	<3A366ACB-20D4-42C7-BBAE-46F643E3A91F@intuitivefuture.com>
	<878581203.20060112153625@ionzoft.com>
	<7.0.0.16.2.20060112154219.029d06c8@zend.com>
	<43C75FEE.7040908@php.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] Re: Named arguments revisited
From: andi@zend.com (Andi Gutmans)

At 12:08 AM 1/13/2006, Lukas Smith wrote:
>Andi Gutmans wrote:
>>In my opinion, as Ilia stated passing an associative array does the 
>>job quite well for the use-case where named arguments would be useful.
>>Sure it might be a tad-bit sexier that you don't have to write 
>>array() but the truth is that the implementation would probably 
>>still use an array. Unlike Ada which has extremely strict typing, 
>>in PHP in most cases we wouldn't be able to optimize away the named 
>>parameters, meaning that we'd probably do the array() trick anyway.
>
>You are argueing from a php internal level. Named parameters are 
>useful for situations where you have alot of parameters. I think 
>people have shown that this may not be the common case, but its 
>still very much real.

Yeah I know. I did my small share of Ada hacking in the past :)

>People have shown ways to handle default values fairly efficiently. 
>However this still dances around the language level documentation.
>
>It also dances around the need for error handling entirely. Of 
>course you could also hack in some checks using array_diff() to 
>determine if there are any unwanted parameters and then trigger an error.
>
>Now we have not even addressed the potential for type hinted parameters.
>
>However this means adding a fair amount of LOC, that are much less 
>obvious to read. Performance in this case is not the main factor, 
>but if oyu add in a call to array_diff() with a !empty() if 
>statement I think its hard to argue that the performance would be equal either.
>
>Also contrary to alot of the things we have added since php 5.x I 
>think this language feature would be much more obvious and easy to 
>grasp even without reading any documentation on it. As such it very 
>much fits the PHP style and has very little risk of obfuscating the language.
>
>Now obviously there would have to be someone to implement it, but I 
>see no "design" reason to not allow this feature in.

I agree it wouldn't be hard to grasp but I think having many ways to 
do the same thing in a language is not a good thing. Look where it 
took Perl. It's not only about having someone to implement that (we 
could resolve that easily) but whether we should have it in the 
language. You shouldn't implement everything you can.
Again, I truly understand the cases where it's useful but I think 
these cases are relatively few and don't warrant such a major change 
and going down the route of creating two completely separate calling styles.

Andi