Re: RE: [RFC] Fast Parameter Parsing API

From: 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)

« previous php.internals (#74491) next »