Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68869
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5224F2EC.2090609@sugarcrm.com>
References: <52243BA6.5040905@sugarcrm.com>
	<CAEZPtU5u+29CxpgDHs6GOoDUU+EWtm-8dr7NL4dufvSq+LZsyw@mail.gmail.com>
	<5224F2EC.2090609@sugarcrm.com>
Date: Mon, 2 Sep 2013 23:43:50 +0200
Message-ID: <CAF+90c_1XyHP9+-fJUm7uTg_DH_tfa3yZc-wkGThKDxiYY5eFw@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Pierre Joye <pierre.php@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e012953acc5ccf804e56d77b4
Subject: Re: [PHP-DEV] [RFC] Skipping parameters take 2
From: nikita.ppv@gmail.com (Nikita Popov)

--089e012953acc5ccf804e56d77b4
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Sep 2, 2013 at 10:19 PM, Stas Malyshev <smalyshev@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

--089e012953acc5ccf804e56d77b4--