Hi! > I already have a mostly-working implementation for named arguments and > unless I missed something critical it does not require us to redo > argument passing. The idea I followed was to keep the argument passing > pretty much as-is, just instead of always pushing on top of the stack to > place named args directly at the correct offsets. So we still have a > stack of positional arguments, they're just inserted out of order. This > will also leave NULL values in between, so they need to be handled as in > your implementation. The only thing you can't handle this way are named
That may work and actually except for the syntax for default pretty much matches what my patch does completely. However what to do with internal functions, especially those using + and *? Not all of them have proper arginfos, and some of them would be pretty hard to describe properly - something like array_intersect_uassoc() for example. Current arginfo for it is completely misleading. > arguments that are not defined in the signature - if we want something > like pythons **kwargs those need to be collected in an HT. I'd likely This however is a question. **kwargs is super-ugly, and the fact that python has 2 sets of optional argument was always annoying for me. We should try to avoid it. Varargs syntax may actually be better there, but the question is where would we keep the names? Would additional hash table arg be on the stack? Wouldn't it clash with how proposed varargs work? Also, what about internals - how the engine knows names of the arguments there? > not support that at first, land basic named args instead and then seek > to merge kwargs into the RFC's for variadics/unpacking. Not supporting this means basically it doesn't solve the problem with options lists, which it is supposed to be the solution for. Also, it's not clear what func_get_args and all other inspection functions would do in such case. Of course, if you drop option lists and allow only pre-defined arguments the task becomes much easier, I agree, but also much less useful for things that **kwargs and such are used. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
