Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77056
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <BLU437-SMTP58AB7AAD02472087BFA873E2C50@phx.gbl>
References: <BLU437-SMTP58AB7AAD02472087BFA873E2C50@phx.gbl>
Date: Thu, 4 Sep 2014 17:56:59 +0400
Message-ID: <CA+9eiLur2RJd93gQvUPi-yEHr=w-x9s43Q1EL6jCP_ZS2THzfw@mail.gmail.com>
To: Bob Weinand <bobwei9@hotmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e013c6d20f2110005023db9b3
Subject: Re: Fast zend_parse_parameters API
From: dmitry@zend.com (Dmitry Stogov)

--089e013c6d20f2110005023db9b3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I like the idea of having a single syntax for all cases, but I don't like
the syntax you propose.
In my opinion, it's syntactically inconsistent, less readable and more
error prone, than the old one (sscanf based) and the FAST_ZPP one that is
already in php-master.

I would also prefer to have an ability to select which function should use
"fast" parameter parsing individually.
(You propose use "fast" for all functions, or enable it per extension)
Using "fast" parsing for all functions may significantly increase code size
and slowdown execution, but we won't know it for sure until we didn't try
it.
Anyway, if we find a good single syntax, we must be able to solve technical
problems.

Opinions and other syntax ideas would help us to do our best :)

Thanks. Dmitry.






On Thu, Sep 4, 2014 at 4:23 PM, Bob Weinand <bobwei9@hotmail.com> 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 globall=
y
> 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).
>
> 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)
>
> 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;
> })
>
>
> 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.
>
> Thanks,
> Bob
>

--089e013c6d20f2110005023db9b3--