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).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php