Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74490
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.2\))
In-Reply-To: <CA+9eiLu7CZwEFS0bRHCdW2+ScnfuCbo+FCT-8HymLm=WZBhfhA@mail.gmail.com>
Date: Mon, 26 May 2014 10:02:30 +0100
Cc: Zeev Suraski <zeev@zend.com>,
 Xinchen Hui <xinchen.h@zend.com>,
 PHP Internals <internals@lists.php.net>,
 Bob Weinand <bobwei9@hotmail.com>,
 Stas Malyshev <smalyshev@sugarcrm.com>,
 Andi Gutmans <andi@zend.com>,
 Nikita Popov <nikita.ppv@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-ID: <D1C446F2-C46C-49C1-B66E-702CA4901F1D@ajf.me>
References: <CA+9eiLuknJ7am5jU4WBN7fGXUcZtbb6axsji8ZnydCJ4P-O9hw@mail.gmail.com> <CABBJUpcNL67-cXyBd=yuWdhZPmHM592Q4-g2PGcyOTS_KsBaqQ@mail.gmail.com> <CA+9eiLvj5GVNQ=1D2=RbenfUCUAPaG3uP5H+yAW=TKd-jEVyjw@mail.gmail.com> <-6285448086228171932@unknownmsgid> <CA+9eiLvUeu0j+sPz-EWeq4VC=Spzc7tseAp4VHqpiFEaxHdLiQ@mail.gmail.com> <67d97efff27b61e45ef74d4f4339b4b3@mail.gmail.com> <962B3020-200F-45D2-8FEC-AD7A0BFDA50E@ajf.me> <CA+9eiLu7CZwEFS0bRHCdW2+ScnfuCbo+FCT-8HymLm=WZBhfhA@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Subject: Re: [PHP-DEV] RE: [RFC] Fast Parameter Parsing API
From: ajf@ajf.me (Andrea Faulds)


On 26 May 2014, at 09:43, Dmitry Stogov <dmitry@zend.com> wrote:

> I more or less like the last option, and actually it's similar to Bob
> original proposal.
> But I see two disadvantages:
> 1) It'll relay on macros with variable arguments and it may be not =
portable
> across all compilers.
> 2) It uses nested macros and it may make a nightmare for finding =
source of
> some syntax mistake in user code.

It could be done without variable arguments, with different syntax. =
Actually, I=92m not sure that syntax can be done *with* them based on =
how inflexible C99=92s variadic macros are.

But the following could work, right?

ZEND_PARSE_PARAMETERS(2, 4, ZP_ARRAY(input) ZP_LONG(offset) ZP_OPTIONAL =
ZP_ZVAL(z_length) ZP_BOOL(preserve_keys))

The syntax is ugly, though. It looks like it should be a function and =
have commas between arguments, but it doesn=92t. You could do something =
like this:

ZEND_PARSE_PARAMETERS(2, 4, (ZP_ARRAY(input), ZP_LONG(offset), =
ZP_OPTIONAL, ZP_ZVAL(z_length), ZP_BOOL(preserve_keys)))

That doesn=92t require variadic macros as it would exploit the way the C =
preprocessor works. However, I=92m not sure that=92s actually an =
improvement, especially because the ZP_* macros would now look horrible, =
having to contain garbage at the beginning and end to cancel out the =
comma. It=92s arguably uglier than the one above it.

If we go for the =93Simpler Variation=94 proposal and don=92t specify =
counts, then this is feasible:

ZEND_PARSE_PARAMETERS((ZP_ARRAY(input), ZP_LONG(offset), ZP_OPTIONAL, =
ZP_ZVAL(z_length), ZP_BOOL(preserve_keys)))

But again, the doubly-nested () syntax is ugly and probably confusing. =
I=92d rather go with the first option, even if it does look a little too =
much like a function. With the =93Simpler Variation=94 proposal, it =
could even look like this:

ZEND_PARSE_PARAMETERS(ZP_ARRAY(input) ZP_LONG(offset) ZP_OPTIONAL =
ZP_ZVAL(z_length) ZP_BOOL(preserve_keys))

Doesn=92t that look nice? :)
--
Andrea Faulds
http://ajf.me/