On Mon, Sep 2, 2013 at 10:19 PM, Stas Malyshev <smalys...@sugarcrm.com>wrote:
> Hi! > > > However I still wonder what prevents to finally implement named > > parameters too, it will provide the same feature while being even more > > For named params, you need to rewrite all args handling, since now it is > a positional array and that doesn't work with named args. On the way > you'd have to refactor zend_parse_parameters to understand named args > (which aren't even named in many internals, so you'd have to add those) > and deal with functions that use + and * in various creative ways and > see how those can be reconciled with named params. And then of course is > the question of by-ref parameters and how to make the syntax handle > those too. Long story short, you'll have to rewrite everything that does > with argument passing, argument receiving or even peeks into arguments. > 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 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 not support that at first, land basic named args instead and then seek to merge kwargs into the RFC's for variadics/unpacking. Nikita
