Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77058
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.11.1409041528120.14638@whisky.home.derickrethans.nl>
References: <BLU437-SMTP58AB7AAD02472087BFA873E2C50@phx.gbl>
	<alpine.DEB.2.11.1409041528120.14638@whisky.home.derickrethans.nl>
Date: Thu, 4 Sep 2014 18:02:26 +0400
Message-ID: <CA+9eiLsJHHoTrNPv0jf4su2KVxxWAxkfX2egPh5W7q4ueb2g=Q@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: Bob Weinand <bobwei9@hotmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1132f2a271a0c105023dcde9
Subject: Re: [PHP-DEV] Fast zend_parse_parameters API
From: dmitry@zend.com (Dmitry Stogov)

--001a1132f2a271a0c105023dcde9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 4, 2014 at 5:32 PM, Derick Rethans <derick@php.net> wrote:

> On Thu, 4 Sep 2014, Bob Weinand wrote:
>
> > After a long time=E2=80=A6 back to our fast_zpp RFC.
> >
> > 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
> >
> > 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).
>
> I am going to need an ifdef anyway, once for < PHP 7 and once for >=3D PH=
P
> 7...
>
> > 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)
>
> I think it makes perfect sense to have two styles. Keep the current zpp
> that we have, and only optimise it with the much less readable versions
> for functions (think strlen()) that are called a lot.
>
> > Also, there is the question about how to structure the API; we (I and
> > Dmitry) basically have now two different proposals:
> >
> >
> > 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);
> >
> > OR
> >
> > 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,
> &replace, &subject, &limit, &zcount) =3D=3D FAILURE) {
>

scanf() is suck as well, but I agree, that it makes no sense to switch from
one bad but working solution to another one.


> As I mentioned before, keep the current zpp working, and add a special
> one for the functions where a faster one really matters.
>

This was an original proposal, that is already in php-master, but I
promised that we will discuss it in some point.

Thanks. Dmitry.


>
> cheers,
> Derick
>
> --
> 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

--001a1132f2a271a0c105023dcde9--