Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77055
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender)
Date: Thu, 4 Sep 2014 15:32:58 +0200 (CEST)
To: Bob Weinand <bobwei9@hotmail.com>
cc: PHP internals <internals@lists.php.net>, Dmitry Stogov <dmitry@zend.com>
In-Reply-To: <BLU437-SMTP58AB7AAD02472087BFA873E2C50@phx.gbl>
Message-ID: <alpine.DEB.2.11.1409041528120.14638@whisky.home.derickrethans.nl>
References: <BLU437-SMTP58AB7AAD02472087BFA873E2C50@phx.gbl>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1077857513-1409837579=:14638"
Subject: Re: [PHP-DEV] Fast zend_parse_parameters API
From: derick@php.net (Derick Rethans)

--8323329-1077857513-1409837579=:14638
Content-Type: TEXT/PLAIN; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Thu, 4 Sep 2014, Bob Weinand wrote:

> After a long time=E2=80=A6 back to our fast_zpp RFC.
>=20
> Initially Dmitry proposed to have two different APIs, one for the fast ve=
rsion, 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=20
> rather propose to use one same public API for both. That API should,=20
> depending on some compile-time flag (per file or globally in=20
> zend_API.h), either convert to the usual variadic style function, or=20
> expand to the new fast variant of API parsing (with directly inlining=20
> parameter type specific functions).

I am going to need an ifdef anyway, once for < PHP 7 and once for >=3D PHP=
=20
7...

> What do you think about having one unified API for both, instead of=20
> the current (like it's in some places in master branch currently)?=20
> (p.s.: The rewrite of the current API can be done safely via some PHP=20
> script I wrote)

I think it makes perfect sense to have two styles. Keep the current zpp=20
that we have, and only optimise it with the much less readable versions=20
for functions (think strlen()) that are called a lot.=20

> Also, there is the question about how to structure the API; we (I and=20
> 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
> OR
>=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;
> })

Both of them very much suck as API compared to:

if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ZZZ|lZ", &regex, &rep=
lace, &subject, &limit, &zcount) =3D=3D FAILURE) {

As I mentioned before, keep the current zpp working, and add a special=20
one for the functions where a faster one really matters.

cheers,
Derick

--=20
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
--8323329-1077857513-1409837579=:14638--