Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47777
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain gregory.net from 216.40.44.125 cause and error)
Message-ID: <4BB91308.1070006@gregory.net>
Date: Sun, 04 Apr 2010 18:30:32 -0400
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Stanislav Malyshev <stas@zend.com>
CC: Hannes Magnusson <hannes.magnusson@gmail.com>, 
 internals@lists.php.net, Rasmus Lerdorf <rasmus@lerdorf.com>
References: <745C5243-EB51-4D43-B036-8A34CDBBB547@gregory.net>	 <4BB68D61.2070301@lerdorf.com> <4BB6938F.7090404@zend.com> <u2l7f3ed2c31004031900o5ea084f7m257c3bcb0e7716cc@mail.gmail.com> <4BB90DB7.6060706@zend.com> <4BB91281.5070603@gregory.net>
In-Reply-To: <4BB91281.5070603@gregory.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Named Parameters
From: gregory@gregory.net (Gregory)

err, sorry, to correct my example:

function abc($a) {
  var_export(func_get_args());
}
abc(4, 'a' => 3);

would output array(0 => 4, 'a' => 3)

Greg

Gregory wrote:
> Those are some good points. I would say with regard to 3, that we have 
> the same problem (sic) with defining arrays in PHP, in terms of it not 
> being clear what results from array(1, 2, 'a' => $b, 4). Although we 
> could perfectly copy the array definition semantics, I think you're 
> right, that abc(1, 2, 'a' => $b, 3) is not really useful in the first 
> place. So with that in mind, we could stop perfectly duplicating 
> "array definition semantics", and instead have the following:
>
> a) Regular parameters cannot appear after named parameters, i.e. 
> abc(1, 2, 'a' => $b) is fine but abc(1, 'a' => $b, 2) is not
>
> b) Because of this, we can easily see where the named parameters start 
> (and indeed if they are present in the call). Then, you can implicitly 
> add a variable to the end of the stack which points to a hash, which 
> contains the named parameters.
>
> c) Then, func_get_args would be extended to check for the presence of 
> this hash, and when it's there, simply merge it on top of the array it 
> would have returned. Thus, if the function was abc($a) and I called it 
> with abc(4, 'a' => 3) then func_get_args() inside abc would give 
> array(0 => 3, 'a' => 3).
>
> The question I have is if we are not copying the array semantics 
> anymore, whether we should have abc('a' => 3) or abc(a => 3). I 
> personally would prefer 'a' => 3 because that allows for variable 
> parameter names.
>
> Greg
>
> Stanislav Malyshev wrote:
>> Hi!
>>
>>> The problem however is when an function accepts varargs (usually named
>>> "...")..... if we however bring in strictct-ish naming convention I
>>> don't see any immediate problems....
>>
>> Varargs shouldn't be a problem and we don't even need ... there - we 
>> can just assume every function has implicit ... at the end (more or 
>> less what we are doing now). We have the following issues to overcome 
>> now:
>>
>> 1. We don't keep the name information on the receiving end. It should 
>> be pretty easy to fix - the parser knows the variable names. So 
>> instead of a number RECV opcode can just get a name, or maybe have 
>> separate name table that corresponds to numbers.
>>
>> 2. We don't have a way to pass the name information on the sending 
>> end - right now we use stack, which would not go well with named 
>> params. We'd probably have to switch to a hashtable - which would 
>> require substantial change to parameter change/receive code - but 
>> should be doable. Though introducing a hashtable may have performance 
>> impact there.
>>
>> 3. Combining named and un-named params can get weird - i.e. 
>> foo(1,2,3) is simple, foo(1, 2, bar => 3) is doable, but foo(1, 2, 
>> bar => 3, 4) would be trouble, since it is not clear at all where 4 
>> should go to. Moreover, catching this situation can be non-trivial, 
>> as right now parsing nested function calls may not keep enough 
>> context for this.
>>
>> 4. varargs can be dealt with by either extending func_get_args() to 
>> provide name information or maybe by having some function that 
>> returns only those args that do not have matching names (that would 
>> make generic options easier to do).
>
>