Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68872
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.123 as permitted sender)
Message-ID: <52250A97.8050406@sugarcrm.com>
Date: Mon, 02 Sep 2013 15:00:55 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Nikita Popov <nikita.ppv@gmail.com>
CC: Pierre Joye <pierre.php@gmail.com>, 
 PHP Internals <internals@lists.php.net>
References: <52243BA6.5040905@sugarcrm.com> <CAEZPtU5u+29CxpgDHs6GOoDUU+EWtm-8dr7NL4dufvSq+LZsyw@mail.gmail.com> <5224F2EC.2090609@sugarcrm.com> <CAF+90c_1XyHP9+-fJUm7uTg_DH_tfa3yZc-wkGThKDxiYY5eFw@mail.gmail.com>
In-Reply-To: <CAF+90c_1XyHP9+-fJUm7uTg_DH_tfa3yZc-wkGThKDxiYY5eFw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Skipping parameters take 2
From: smalyshev@sugarcrm.com (Stas Malyshev)

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