Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74503
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.174 as permitted sender)
Message-ID: <BLU436-SMTP788AB6C165873CFABE38EBE23B0@phx.gbl>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_26F784BE-4501-477F-95F4-B412DED9D3E4"
MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
In-Reply-To: <CAEZPtU4K-y8raOxzL_nkA0p-_3AXZERmcWRBDqnDM6ikNE8c+g@mail.gmail.com>
Date: Mon, 26 May 2014 14:20:42 +0200
CC: Andrea Faulds <ajf@ajf.me>,
 Dmitry Stogov <dmitry@zend.com>,
 Zeev Suraski <zeev@zend.com>,
 Xinchen Hui <xinchen.h@zend.com>,
 PHP Internals <internals@lists.php.net>,
 Stas Malyshev <smalyshev@sugarcrm.com>,
 Andi Gutmans <andi@zend.com>,
 Nikita Popov <nikita.ppv@gmail.com>
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> <D1C446F2-C46C-49C1-B66E-702CA4901F1D@ajf.me> <DUB406-EAS3560576E7F9AB9B54837717E23B0@phx.gbl> <CAEZPtU4K-y8raOxzL_nkA0p-_3AXZERmcWRBDqnDM6ikNE8c+g@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Subject: Re: [PHP-DEV] RE: [RFC] Fast Parameter Parsing API
From: bobwei9@hotmail.com (Bob Weinand)

--Apple-Mail=_26F784BE-4501-477F-95F4-B412DED9D3E4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"

Am 26.5.2014 um 12:11 schrieb Pierre Joye <pierre.php@gmail.com>:
> On Mon, May 26, 2014 at 11:39 AM, Bob Weinand <bobwei9@hotmail.com> =
wrote:
>> Actually, that's exactly my the original API, just with ZP_OPTIONAL =
instead of numbers for counts:
>=20
> Where was it proposed? I missed it.

It wasn't proposed, it just was the initial patch I showed Dmitry when I =
made a small PoC.

>> ZEND_PARSE_PARAMETERS(ZP_ARRAY(input) ZP_LONG(offset) ZP_OPTIONAL =
ZP_ZVAL(z_length) ZP_BOOL(preserve_keys), { return; })
>> (The return at the end is the error branch)
>>=20
>> I still prefer it that way, but Dmitry doesn't...
>=20
> Pretty much the same to me, with the same conclusion as well, sadly.
>=20
> I do not find it more readable than the one in the RFC and it does not
> solve the double or sometimes triple declarations of the arguments.
> And I do not even want to think about how it will look if we implement
> named arguments (let face it, we will have them).

I highly doubt we can solve that problem. I think of it being =
impossible.
(When not trying abysmal things like parsing code upon compiling)

>> It's the most readable I still think.
>=20
> zpp current usage is much more readable to me and less error prone
> while writing (clang plugin helping to check the syntax, see Johannes
> tools).

Actually, with the new implementation, you don't even need a plugin for
checking types etc.. Even gcc does that for you with a nice warning.

> May I point you to my questions in this thread about extending the
> reflection struct, add the necessary info (types) and maybe do the
> naming args while being at it?

See above, I think of it as impossible.

> Cheers,
> --=20
> Pierre
>=20
> @pierrejoye | http://www.libgd.org


Bob=

--Apple-Mail=_26F784BE-4501-477F-95F4-B412DED9D3E4--