Re: RE: [RFC] Fast Parameter Parsing API
| From: | Bob Weinand | Date: | Mon, 26 May 2014 09:39:56 +0000 |
| Subject: | Re: RE: [RFC] Fast Parameter Parsing API | ||
| References: | 1 2 3 4 5 6 7 8 9 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-74491@lists.php.net to get a copy of this message | ||
> Am 26.05.2014 um 11:03 schrieb "Andrea Faulds" <ajf@ajf.me>:
>> 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’m not sure
> that syntax can be done *with* them based on how inflexible C99’s 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’t. 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’t require variadic macros as it would exploit the way the C preprocessor works.
> However, I’m not sure that’s 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’s arguably uglier than the one above it.
>
> If we go for the “Simpler Variation” proposal and don’t 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’d rather go with the
> first option, even if it does look a little too much like a function. With the “Simpler
> Variation” 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’t that look nice? :)
> --
> Andrea Faulds
> http://ajf.me/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
Actually, that's exactly my the original API, just with ZP_OPTIONAL instead of numbers for
counts:
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)
I still prefer it that way, but Dmitry doesn't...
It's the most readable I still think.
That's for me more important tgan being able to debug the macro. (Compiler still is useful for
debugging wrong usage of macros here)
Bob Weinand (iPhone)