On Tue, Sep 3, 2013 at 12:00 AM, Stas Malyshev <smalys...@sugarcrm.com>wrote:
> 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. > I think at some point you just need to go for "good enough" rather than "optimal support for everything". If we don't support the rather special case of internal functions having variadic arguments followed by fixed ones, I wouldn't consider that too tragic. > > 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, Yes, this is likely better in PHP's context. After all our array structure supports both continuous arrays (for normal varargs) and dictionaries (for kwargs), so I think we should be able to combine those. > but the question is where would we keep the names? Would additional hash > table arg be on the stack? Might be simpler to pass it via function_state. > Also, what about internals - how the engine knows names of the > arguments there? > What do you mean by this? > 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. > I think the main use of named args is in specifying existing arguments out of order. kwargs is a nice addition for minor use cases. I'll think about how to support those a bit more. Nikita
