Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68979
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEZPtU47VVdGscUBUbcnh6PAQDfP1FtpgnDHJ1=RrFoMCgQ0Sw@mail.gmail.com>
References: <CAF+90c85v_VTPTPanBcTJ70Ff6pm6fRgAGs4n1uoaA+B9UZg=w@mail.gmail.com>
	<CAEZPtU47VVdGscUBUbcnh6PAQDfP1FtpgnDHJ1=RrFoMCgQ0Sw@mail.gmail.com>
Date: Mon, 9 Sep 2013 21:57:55 +0200
Message-ID: <CAF+90c9+4AjUxSLysJY4dQKAEWxGfbtJAVSnQL7xUpC_27ss9w@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1133458ee5705b04e5f8cde4
Subject: Re: [PHP-DEV] [RFC] Named parameters
From: nikita.ppv@gmail.com (Nikita Popov)

--001a1133458ee5705b04e5f8cde4
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Sep 7, 2013 at 9:52 AM, Pierre Joye <pierre.php@gmail.com> wrote:

> In no particular order:
>
> . Warning: Cannot pass positional arguments after named arguments.
> Aborting argument unpacking in %s on line %d
>
> Would it make more sense to make it a fatal error? As the code will
> likely not work as expected, at all. It could be a bit too harsh but
> as it is a new feature, there is no BC impact and ensure good usage.
>

I agree that continuing the function call in that case is a bad idea, but I
also really dislike throwing fatal errors when dynamic constructors are
used. An exception would be optimal here (no continued function call, but
easily recoverable), but I know I'm not allowed to introduce those...


> . would it make sense to have an alternative zend API to fetch one or
> more argument using its name? I can see a couple of usages for such a
> function
>

I provide this function:

    ZEND_API int zend_get_arg_num(zend_uint *arg_num_target, zend_function
*fn, char *name, int name_len, zend_ulong hash_value TSRMLS_DC);

Using it you can get the argument number from a parameter name and based on
that lookup the value of the argument as usual. Is that sufficient?


> - It would be nice to add (later once the RFC is more stable) docs
> about which impacts and changes are expected for extension developers
>

Yes, sure :)

- Do you have a fork for this RFC? Much easier to test, create snaps, etc.
>

Yes, it's the namedParams branch of my github fork:
https://github.com/nikic/php-src/tree/namedParams

Nikita

--001a1133458ee5705b04e5f8cde4--