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).
-- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
