Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77054
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.200 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <BLU437-SMTP58AB7AAD02472087BFA873E2C50@phx.gbl>
Date: Thu, 4 Sep 2014 13:27:43 +0100
Cc: PHP internals <internals@lists.php.net>,
 Dmitry Stogov <dmitry@zend.com>
Content-Transfer-Encoding: quoted-printable
Message-ID: <EC59D3D7-00CF-40E5-933D-9A9AFA91FFC4@ajf.me>
References: <BLU437-SMTP58AB7AAD02472087BFA873E2C50@phx.gbl>
To: Bob Weinand <bobwei9@hotmail.com>
Subject: Re: [PHP-DEV] Fast zend_parse_parameters API
From: ajf@ajf.me (Andrea Faulds)


On 4 Sep 2014, at 13:23, Bob Weinand <bobwei9@hotmail.com> wrote:

> After a long time=85 back to our fast_zpp RFC.
>=20
> Initially Dmitry proposed to have two different APIs, one for the fast =
version, one for current version:
> #if FAST_ZPP
>    /* new API */
> #else
>    /* old style zend_parse_parameters API */
> #endif
>=20
> I don't really like the idea of having two different APIs, so I'd =
rather propose to use one same public API for both.
> That API should, depending on some compile-time flag (per file or =
globally in zend_API.h), either convert to the usual variadic style =
function, or expand to the new fast variant of API parsing (with =
directly inlining parameter type specific functions).
>=20
> What do you think about having one unified API for both, instead of =
the current (like it's in some places in master branch currently)?
> (p.s.: The rewrite of the current API can be done safely via some PHP =
script I wrote)

This is actually quite an interesting idea. If you think about it, =
there=92s no reason the macros couldn=92t expand to =
zend_parse_parameters.

>=20
> Also, there is the question about how to structure the API; we (I and =
Dmitry) basically have now two different proposals:
>=20
>=20
> ZEND_PARSE_PARAMETERS_START(3, 5)
>    Z_PARAM_ZVAL(regex)
>    Z_PARAM_ZVAL(replace)
>    Z_PARAM_ZVAL(subject)
>    Z_PARAM_OPTIONAL
>    Z_PARAM_LONG(limit)
>    Z_PARAM_ZVAL_EX(zcount, 0, 1)
> ZEND_PARSE_PARAMETERS_END_EX(return);
>=20
>=20
> OR
>=20
>=20
> zend_parse_parameters(ZPP_ZVAL(regex) ZPP_ZVAL(replace) =
ZPP_ZVAL(subject) ZPP_OPTIONAL ZPP_LONG(limit) ZPP_ZVAL_EX(zcount, =
ZPP_BY_REF), {
>    return;
> })
>=20
>=20
> We'd like to have some discussions about what API to use for the next =
years. If you have some better API, feel free to propose it.

Neither is that good, though I might prefer the first one.

Perhaps we should move this out of functions altogether, and instead =
have parameter types be attributes of the function? I=92m not sure if =
it=92s possible, but it would be awesome if we could just put the types =
where we have our parameter names in our info structs, and it would just =
magically call the C function with the right types.
--
Andrea Faulds
http://ajf.me/