zend_parse_parameters() improvements

12 years ago by Nikita Popov — view source

unread

Some deficiencies in zpp have been constrai
ning the implementation of common scenarios such as 'allow integer or NULL'*
or the more general 'allow different types for an argument'**.

So I propose the changes in this branch:

https://github.com/cataphract/php-src/compare/zpp_improv

Please see the commit messages for the rationale.

*Example:
https://github.com/php/php-src/pull/13
(again more recently on
https://github.com/php/php-src/pull/133 )
**
Example:
http://lxr.php.net/xref/PHP_TRUNK/ext/intl/timezone/timezone_methods.cpp#143
In this case, NULL, int and string are allowed. This would become much
simpler:

if (arg == NULL || Z_TYPE_PP(arg) == IS_NULL) {
se = TimeZone::createEnumeration();
} else {
long l;
char *s;
int s_len;
if (zend_parse_parameter(ZEND_PARSE_PARAMS_QUIET,
1 TSRMLS_DC, arg, "l", &l) == SUCCESS) {
TimeZone::createEnumeration((int32_t) l);
} else if (zend_parse_parameter(ZEND_PARSE_PARAMS_QUIET,
1 TSRMLS_DC, arg, "s", &s, &s_len) == SUCCESS) {
TimeZone::createEnumeration(s);
} else {
//raise errror
}
}

+1 The long/null issue comes up every once in a while. This is really useful.

Nikita

12 years ago by Stas Malyshev — view source

unread

Hi!

Some deficiencies in zpp have been constrai
ning the implementation of common scenarios such as 'allow integer or
NULL'* or the more general 'allow different types for an argument'**.

So I propose the changes in this branch:

https://github.com/cataphract/php-src/compare/zpp_improv

This looks interesting. I have a bit different idea about how to make
"parameter not passed" scenario - see
https://wiki.php.net/rfc/skipparams - but having something like l! would
work in that case too.
It'd be nice to have a description of these as an RFC though - so we
could use it in the docs, when updating READMEs and for reference -
tracking down commit messages is not very convenient.

Example:
http://lxr.php.net/xref/PHP_TRUNK/ext/intl/timezone/timezone_methods.cpp#143
In this case, NULL, int and string are allowed. This would become much
simpler:

if (arg == NULL || Z_TYPE_PP(arg) == IS_NULL) {
se = TimeZone::createEnumeration();
} else {
long l;
char *s;
int s_len;
if (zend_parse_parameter(ZEND_PARSE_PARAMS_QUIET,
1 TSRMLS_DC, arg, "l", &l) == SUCCESS) {
TimeZone::createEnumeration((int32_t) l);
} else if (zend_parse_parameter(ZEND_PARSE_PARAMS_QUIET,
1 TSRMLS_DC, arg, "s", &s, &s_len) == SUCCESS) {
TimeZone::createEnumeration(s);
} else {
//raise errror
}

Wait, didn't you say applying zpp to arg as l, then as s would change
it? Or your function doesn't change it?

In any case, I think giving access to single-parameter parsing is a good
idea and allows functions to implement complex cases in more consistent
manner - right now I know there are some functions that return different
error messages than zpp does when they parse arguments, for example -
this can be fixes.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

12 years ago by Gustavo Lopes — view source

unread

Em Thu, 19 Jul 2012 01:11:38 +0200, Stas Malyshev smalyshev@sugarcrm.com
escreveu:

Example:
http://lxr.php.net/xref/PHP_TRUNK/ext/intl/timezone/timezone_methods.cpp#143
In this case, NULL, int and string are allowed. This would become much
simpler:

if (arg == NULL || Z_TYPE_PP(arg) == IS_NULL) {
se = TimeZone::createEnumeration();
} else {
long l;
char *s;
int s_len;
if (zend_parse_parameter(ZEND_PARSE_PARAMS_QUIET,
1 TSRMLS_DC, arg, "l", &l) == SUCCESS) {
TimeZone::createEnumeration((int32_t) l);
} else if (zend_parse_parameter(ZEND_PARSE_PARAMS_QUIET,
1 TSRMLS_DC, arg, "s", &s, &s_len) == SUCCESS) {
TimeZone::createEnumeration(s);
} else {
//raise errror
}

Wait, didn't you say applying zpp to arg as l, then as s would change
it? Or your function doesn't change it?

Yes, the zval is potentially changed in both calls (that's why the
argument is passed with double indirection). But this is not a problem
here (in fact, it simplifies resource management -- since the second
zend_parse_parameter() changes the zval in the stack, the engine can
reclaim the zval and string automatically when the function returns).

There's to argument if its processing fails. zend_parse_parameters()
(plural) changes the arguments only until it fails. Yes, whether an
argument is changed or not depends on its position relative to the failing
argument.

Since zend_parse_parameter() takes only one argument this is not a problem
-- supposedly, you call zend_parse_parameter() successfully only once. In
any case, you can always copy the zval yourself.

In any case, I think giving access to single-parameter parsing is a good
idea and allows functions to implement complex cases in more consistent
manner - right now I know there are some functions that return different
error messages than zpp does when they parse arguments, for example -
this can be fixes.

--
Gustavo Lopes

12 years ago by Sara Golemon — view source

unread

For this type of situation, you could equally go with something like:

zval *val;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "n", &val) == FAILURE)
{ RETURN_NULL(); }

Where the 'n' type looks for a numeric value: IS_LONG/IS_DOUBLE kept as is,
IS_STRING/IS_OBJECT (with toString() behavior) converted to
IS_LONG/IS_DOUBLE if possible, anything else an error.

And for methods where a non-numeric string makes sense:
'N' type would not error on other types, but pass them through. It would
differ from the 'z' type only in that IS_STRING/IS_OBJECT would attempt to
convert to IS_LONG/IS_DOUBLE if possible, but unlike 'n' it wouldn't panic.

-Sara

On Wed, Jul 18, 2012 at 2:05 PM, Gustavo Lopes glopes@nebm.ist.utl.ptwrote:

Some deficiencies in zpp have been constrai
ning the implementation of common scenarios such as 'allow integer or
NULL'* or the more general 'allow different types for an argument'**.

So I propose the changes in this branch:

https://github.com/cataphract/**php-src/compare/zpp_improv https://github.com/cataphract/php-src/compare/zpp_improv

Please see the commit messages for the rationale.

*Example:
https://github.com/php/php-**src/pull/13 https://github.com/php/php-src/pull/13
(again more recently on
https://github.com/php/php-**src/pull/133 https://github.com/php/php-src/pull/133)
**
Example: http://lxr.php.net/xref/PHP_TRUNK/ext/intl/timezone/
timezone_methods.cpp#143http://lxr.php.net/xref/PHP_TRUNK/ext/intl/timezone/timezone_methods.cpp#143
In this case, NULL, int and string are allowed. This would become much
simpler:

if (arg == NULL || Z_TYPE_PP(arg) == IS_NULL) {
se = TimeZone::createEnumeration();
} else {
long l;
char *s;
int s_len;
if (zend_parse_parameter(ZEND_**PARSE_PARAMS_QUIET,
1 TSRMLS_DC, arg, "l", &l) == SUCCESS) {
TimeZone::createEnumeration((**int32_t) l);
} else if (zend_parse_parameter(ZEND_PARSE_PARAMS_QUIET,
1 TSRMLS_DC, arg, "s", &s, &s_len) == SUCCESS) {
TimeZone::createEnumeration(s);
} else {
//raise errror
}
}

--
Gustavo Lopes

12 years ago by Gustavo Lopes — view source

unread

Em Thu, 19 Jul 2012 20:36:45 +0200, Sara Golemon pollita@php.net
escreveu:

For this type of situation, you could equally go with something like:

zval *val;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "n", &val) ==
FAILURE)
{ RETURN_NULL(); }

Where the 'n' type looks for a numeric value: IS_LONG/IS_DOUBLE kept as
is, IS_STRING/IS_OBJECT (with toString() behavior) converted to
IS_LONG/IS_DOUBLE if possible, anything else an error.

I don't see how this applies to 'this type of situation' at all (be it the
long-or-null case or the the other example I gave).

Most commonly one needs either a long or a double, not something that may
be a double or a long. Either because one's wrapping a native method that
takes an integer or a floating point type or because the specific
algorithm being implemented calls for one of them.

Such a type would certainly be useful in other situations, but it's
irrelevant for the examples I give and similar ones. And in any case, the
specific semantics you proposed are inconsistent with the current
conversion rules, which accept bool and null for numeric types (but yes,
they probably shouldn't).

And for methods where a non-numeric string makes sense:
'N' type would not error on other types, but pass them through. It would
differ from the 'z' type only in that IS_STRING/IS_OBJECT would attempt
to convert to IS_LONG/IS_DOUBLE if possible, but unlike 'n' it wouldn't
panic.

Again, I'm not sure which problem we're solving here. We could have a new
type that converts to IS_LONG if the argument is a valid integer, double,
bool, string or even object, leaves at IS_NULL if the argument is null and
fails otherwise. THAT would solve the long-or-null problem. But it would
require new types to extend to booleans and doubles and new type
characters one would have to memorize. We can already query for null-ness
with ! and I think my proposal is consistent with the spirit of the
current interface, so the only point where this alternative would be
superior would be in that it would require one less local variable.

--
Gustavo Lopes

12 years ago by Sara Golemon — view source

unread

Then I'm not sure what problem you're trying to solve either. :/

On Thu, Jul 19, 2012 at 12:08 PM, Gustavo Lopes glopes@nebm.ist.utl.ptwrote:

Em Thu, 19 Jul 2012 20:36:45 +0200, Sara Golemon pollita@php.net
escreveu:

For this type of situation, you could equally go with something like:

zval *val;
if (zend_parse_parameters(ZEND_**NUM_ARGS() TSRMLS_CC, "n", &val) ==
FAILURE)
{ RETURN_NULL(); }

Where the 'n' type looks for a numeric value: IS_LONG/IS_DOUBLE kept as
is, IS_STRING/IS_OBJECT (with toString() behavior) converted to
IS_LONG/IS_DOUBLE if possible, anything else an error.

I don't see how this applies to 'this type of situation' at all (be it the
long-or-null case or the the other example I gave).

Most commonly one needs either a long or a double, not something that may
be a double or a long. Either because one's wrapping a native method that
takes an integer or a floating point type or because the specific algorithm
being implemented calls for one of them.

Such a type would certainly be useful in other situations, but it's
irrelevant for the examples I give and similar ones. And in any case, the
specific semantics you proposed are inconsistent with the current
conversion rules, which accept bool and null for numeric types (but yes,
they probably shouldn't).

And for methods where a non-numeric string makes sense:

'N' type would not error on other types, but pass them through. It would
differ from the 'z' type only in that IS_STRING/IS_OBJECT would attempt
to convert to IS_LONG/IS_DOUBLE if possible, but unlike 'n' it wouldn't
panic.

Again, I'm not sure which problem we're solving here. We could have a new
type that converts to IS_LONG if the argument is a valid integer, double,
bool, string or even object, leaves at IS_NULL if the argument is null and
fails otherwise. THAT would solve the long-or-null problem. But it would
require new types to extend to booleans and doubles and new type characters
one would have to memorize. We can already query for null-ness with ! and I
think my proposal is consistent with the spirit of the current interface,
so the only point where this alternative would be superior would be in that
it would require one less local variable.

--
Gustavo Lopes

12 years ago by Nikita Popov — view source

unread

Then I'm not sure what problem you're trying to solve either. :/

This solves two problems:

a) Integer parameters cannot currently be skipped using NULL. This
issue comes up every now and then. E.g. see
https://github.com/php/php-src/pull/133.

b) If you need more complex argument handling you currently have to
fetch the value as z and then use some convert_to_* function. But
those convert_to_* functions behave differently than zpp. So a
function for parsing a single parameter is exposed too.

Nikita

12 years ago by Stas Malyshev — view source

unread

Hi!

This solves two problems:

a) Integer parameters cannot currently be skipped using NULL. This
issue comes up every now and then. E.g. see
https://github.com/php/php-src/pull/133.

Again, I think param skipping RFC addresses this better, but having some
way to see if param was supplied or not can be useful. Right now since
there's no "out of range" value for ints - like NULL for pointers - it's
impossible to know it. So this is one thing that's indeed missing for
all non-pointer types in zpp.

b) If you need more complex argument handling you currently have to
fetch the value as z and then use some convert_to_* function. But
those convert_to_* functions behave differently than zpp. So a
function for parsing a single parameter is exposed too.

I agree that being able to use zpp on single parameter might lead to a
cleaner code - we've had some bugs where handmade args parsing was done
wrong. So I think this RFC is a good addition.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

12 years ago by Sara Golemon — view source

unread

Okay, well... the main pieces of feedback I'd give on it then is to not
change the behavior of the '!' modifier. That's bad BC. Rather, introduce
a new modifier for checking if a parameter was passed. Secondly, make
these two separate patches as the new modifier is a separate feature from
the single-arg parameter parsing.

FWIW, there are a few examples of this being handled by defining the
default value of the parameter to something non-sensical (such as a length
of -1), then doing zpp with "|l!" would leave the default -1 alone when
NULL is passed, and you can treat as "not passed". Granted this is a bit
of a hack and won't work for all situations. Your approach is more
comprehensive, just saying that for many cases it's not strictly needed.

-Sara

Then I'm not sure what problem you're trying to solve either. :/

This solves two problems:

a) Integer parameters cannot currently be skipped using NULL. This
issue comes up every now and then. E.g. see
https://github.com/php/php-src/pull/133.

b) If you need more complex argument handling you currently have to
fetch the value as z and then use some convert_to_* function. But
those convert_to_* functions behave differently than zpp. So a
function for parsing a single parameter is exposed too.

Nikita

12 years ago by Nikita Popov — view source

unread

Okay, well... the main pieces of feedback I'd give on it then is to not
change the behavior of the '!' modifier. That's bad BC.
The behavior for pointer-params isn't changed. Only non-pointer params
will then accept the additional is_null argument.

FWIW, there are a few examples of this being handled by defining the default
value of the parameter to something non-sensical (such as a length of -1),
then doing zpp with "|l!" would leave the default -1 alone when NULL is
passed, and you can treat as "not passed". Granted this is a bit of a hack
and won't work for all situations. Your approach is more comprehensive,
just saying that for many cases it's not strictly needed.
If I'm not much mistaken this is not actually possible. NULL is
interpreted by PHP as a zero-y value. So the variable will be just set
to 0 and you have no way to discern a real 0 and NULL.

Nikita

12 years ago by Gustavo Lopes — view source

unread

Em Fri, 20 Jul 2012 00:20:49 +0200, Sara Golemon pollita@php.net
escreveu:

Okay, well... the main pieces of feedback I'd give on it then is to not
change the behavior of the '!' modifier. That's bad BC. Rather,
introduce
a new modifier for checking if a parameter was passed. Secondly, make
these two separate patches as the new modifier is a separate feature from
the single-arg parameter parsing.

FWIW, there are a few examples of this being handled by defining the
default value of the parameter to something non-sensical (such as a
length
of -1), then doing zpp with "|l!" would leave the default -1 alone when
NULL is passed, and you can treat as "not passed". Granted this is a bit
of a hack and won't work for all situations. Your approach is more
comprehensive, just saying that for many cases it's not strictly needed.

Stas managed to confuse you :)

On an implementation level, this has nothing to do with default parameter
values and unpassed parameters. As always, if you don't pass an argument,
the pointers you give to zpp won't be touched. The behavior of ! is not
changed insofar as it was not possible to use it with l, d or b (well
actually it was ignored, so if anyone used l! their code will break as you
now have to pass an extra argument, but it was wrong in the first place).

Default parameters and unpassed parameters enter the scene because it's
idiomatic to pass NULL to have the same effect as not passing that
parameter.

Consider this hypothetical internal function with signature:

mb_substr(string $str, int $start [, int $length [, string $encoding ]])

Let's also imagine we want that the effect of not passing $length cannot
be triggered by a specific value of $length (like -1) because the whole
integer domain is used for something else. We have this check:

if (ZEND_NUM_ARGS() < 3) { /* do special stuff */ }

But now I cannot pass $encoding and not pass $length. I also can't wrap
the function and pass-through arguments in an easy fashion.

An idiomatic solution for this is to use NULL as a special value. In
userspace:

function mb_substr($str, $start, $length=NULL, $encoding=NULL) {
if ($length === null) { /* do special stuff */ }

However, the same is not possible with zpp because if we use 'l' and we
send NULL, we'll get 0, which we cannot distinguish from an actual 0 being
passed (or false, etc.).

The first commit in the branch solves this problem. We could write:

char *str, *encoding = NULL;
int str_len, encoding_len;
long start, length;
zend_bool length_is_null = 0;
zend_parse_parameters(..., "sl|l!s!, &str, &str_len, &start,
&length, &length_is_null, &encoding)

Then we have length_is_null == 0 <=> $length was not passed or NULL was
its value (just like the userland check above).

--
Gustavo Lopes

12 years ago by Stas Malyshev — view source

unread

Hi!

Default parameters and unpassed parameters enter the scene because it's
idiomatic to pass NULL to have the same effect as not passing that
parameter.

Actually, as it never worked with int parameters, I'd not really call it
idiomatic just yet.

I was just thinking - since we have basically no code relying on this,
why introduce rather artificial concept of "null means no parameter"
(which I'm sure won't work in all cases and won't be expected in all
cases) if we can have perfectly good concept "default means no
parameter" which won't clash with any existing code?

Note that this still will require something like l! - I'm actually
working right now on finding all the places we have something like this
for my default params patch - so I agree with that part of the argument.
I'm just not sure adding that semantics to null is the best idea, since
null can be a variable value and having something like mb_substr($foo,
0, $this->length) suddenly behave differently when $this->length is null
would be somewhat unexpected effect.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

12 years ago by Gustavo Lopes — view source

unread

Em Fri, 20 Jul 2012 02:07:31 +0200, Stas Malyshev smalyshev@sugarcrm.com
escreveu:

Default parameters and unpassed parameters enter the scene because it's
idiomatic to pass NULL to have the same effect as not passing that
parameter.

Actually, as it never worked with int parameters, I'd not really call it
idiomatic just yet.

OK I should have qualified my statement -- it's idiomatic in userland.

I was just thinking - since we have basically no code relying on this,
why introduce rather artificial concept of "null means no parameter"
(which I'm sure won't work in all cases and won't be expected in all
cases) if we can have perfectly good concept "default means no
parameter" which won't clash with any existing code?

Note that this still will require something like l! - I'm actually
working right now on finding all the places we have something like this
for my default params patch - so I agree with that part of the argument.
I'm just not sure adding that semantics to null is the best idea, since
null can be a variable value and having something like mb_substr($foo,
0, $this->length) suddenly behave differently when $this->length is null
would be somewhat unexpected effect.

I don't deny that 'default' would be clearer than 'null' (and certainly
clearer than 3 commas in a row), but I wouldn't call this strategy
innovative. A lot of userland code out there uses NULL in this fashion.

I already had the opportunity to express my reservations about your
proposal -- namely the effort required to purge ZEND_NUM_ARGS() usage vs
the benefit, but since 1) you're apparently doing the work, 2) eases
somewhat the way for named parameters, and 3) the default keyword was
added, it doesn't seem so bad now.

And just to clear, I agree with Sara that ! (both for l/d/b and the
pointer types) should not be redefined to "parameter was passed". But it's
my understanding that that's not what you're planning.

--
Gustavo Lopes

12 years ago by Stas Malyshev — view source

unread

Hi!

And just to clear, I agree with Sara that ! (both for l/d/b and the
pointer types) should not be redefined to "parameter was passed". But it's
my understanding that that's not what you're planning.

I didn't have yet a good generic way to handle l/d/b with 'default' - in
many cases for now I prohibited using 'default' in current code in this
context - but if we had some improvement that allows to do it - like
your patch, though not with ! - it would be definitely an improvement.
I'll be done with rest of ZEND_NUM_ARGS() cleanup probably by the end of
next week, and then I could look into integrating your changes, I think
it makes my patch work much better in some cases :)

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

12 years ago by Nikita Popov — view source

unread

I was just thinking - since we have basically no code relying on this,
why introduce rather artificial concept of "null means no parameter"
(which I'm sure won't work in all cases and won't be expected in all
cases) if we can have perfectly good concept "default means no
parameter" which won't clash with any existing code?
I'd just like to point out that I wouldn't bet much on the parameter
skipping via default making it in. I don't want to extrapolate too
much, but from what I've gathered the feature has rather bad community
support. At least as far as I can tell, people are really interested
in having named parameters, but would rather not have parameter
skipping as implemented.

But that's getting off-topic :/

Nikita

12 years ago by Stas Malyshev — view source

unread

Hi!

support. At least as far as I can tell, people are really interested
in having named parameters, but would rather not have parameter
skipping as implemented.

Which people? So far I've got only one person objecting - namely Gustavo

and he's OK with it with my changes as far as I can see. Do you have
any objections to it? Please tell me so I could accommodate them. As for
named parameters - it's fine but I don't see how one precludes the
other. Named parameters is a big thing, and I don't see anybody working
on it or even considering to work on it, so I don't see how you can
compare something that is purely theoretical to a feature that has RFC
and implementation.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

12 years ago by Pierre Joye — view source

unread

hi!

Okay, well... the main pieces of feedback I'd give on it then is to not
change the behavior of the '!' modifier. That's bad BC.

Fully agreed, if we can avoid the introduction of yet another set of
#ifdef, then I'm all for it.

Rather, introduce
a new modifier for checking if a parameter was passed. Secondly, make
these two separate patches as the new modifier is a separate feature from
the single-arg parameter parsing.

Agreed here too.

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

12 years ago by Gustavo Lopes — view source

unread

Em Sat, 21 Jul 2012 13:13:23 +0200, Pierre Joye pierre.php@gmail.com
escreveu:

Okay, well... the main pieces of feedback I'd give on it then is to not
change the behavior of the '!' modifier. That's bad BC.

Fully agreed, if we can avoid the introduction of yet another set of
#ifdef, then I'm all for it.

Rather, introduce
a new modifier for checking if a parameter was passed. Secondly, make
these two separate patches as the new modifier is a separate feature
from the single-arg parameter parsing.

Agreed here too.

In the interest of a meaningful discussion, please read the proposal and
the rest of the thread (or at least the other responses to the message you
were replying to).

To reiterate: this proposal has nothing with Stas' proposal and
passed/unpassed/default parameters except insofar as it would alleviate
the need for having a mechanism to detect whether a parameter was skipped.
One argument raised against skipparams was 'use NULL instead'. Ignoring
the fact that many functions have non-NULL default parameters, this is
difficult to do with non-string scalars in internal functions, which under
my proposal would no longer be the case.

In any case, my proposal is not at odds with Stas'. If you think 'default'
is useful in userland (where the problems the proposed changes address do
not exist), you will still find Stas' proposal compelling.

It is not redundant either. You may want to use null-or-scalar in
mandatory arguments. And if you want a skippable non-string scalar
argument in an internal function, you will nevertheless probably want to
assign it a default value (otherwise you'd have something without a
parallel in user-space -- a skippable argument without a default value),
and NULL will be the logical choice in many cases. Any wrapper in
userspace would look weird if you relied exclusively on skipparams.
Instead of:

function userland_wrapper($a, $b=null) {
return internal_func(2*$1, $b === null ? null : 2 * $b);
}

you would need:

function userland_wrapper($a, $b=null) {
$args = func_get_args();
$args[0] *= 2;
if (isset($args[1])) {
$args[1] *= 2;
} else {
unset($args[1]);
}
call_user_func_array('internal_func', $args);
}

--
Gustavo Lopes

12 years ago by Pierre Joye — view source

unread

hi Gustavo,

Em Sat, 21 Jul 2012 13:13:23 +0200, Pierre Joye pierre.php@gmail.com
escreveu:

Okay, well... the main pieces of feedback I'd give on it then is to not
change the behavior of the '!' modifier. That's bad BC.

Fully agreed, if we can avoid the introduction of yet another set of
#ifdef, then I'm all for it.

Rather, introduce
a new modifier for checking if a parameter was passed. Secondly, make
these two separate patches as the new modifier is a separate feature from
the single-arg parameter parsing.

Agreed here too.

In the interest of a meaningful discussion, please read the proposal and the
rest of the thread (or at least the other responses to the message you were
replying to).

Meaningful discussions include alternative or related areas, and
that's where Sarah's post is damned relevant to this thread. And I
expressed my support to her comment.

Now, I may indeed missed one argument or another is this verbose
discussion, but my reply is to Sarah, to give her my support to what
she proposed, nothing more, nothing less.

However I would strongly suggest you to begin to write a RFC with all
details required to take an informed decision. Please use text not
source codes links to explain something :).

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

11 years ago by Nikita Popov — view source

unread

On Wed, Jul 18, 2012 at 11:05 PM, Gustavo Lopes glopes@nebm.ist.utl.ptwrote:

Some deficiencies in zpp have been constrai
ning the implementation of common scenarios such as 'allow integer or
NULL'* or the more general 'allow different types for an argument'**.

So I propose the changes in this branch:

https://github.com/cataphract/php-src/compare/zpp_improv

What's the state of this?

Nikita

11 years ago by Gustavo Lopes — view source

unread

Em 2012-12-19 22:07, Nikita Popov escreveu:

On Wed, Jul 18, 2012 at 11:05 PM, Gustavo Lopes
glopes@nebm.ist.utl.pt wrote:

Some deficiencies in zpp have been constrai
ning the implementation of common scenarios such as allow integer or
NULL* or the more general allow different types for an argument**.

So I propose the changes in this branch:

https://github.com/cataphract/php-src/compare/zpp_improv [2]

Whats the state of this?

I'll try to find the energy to write the RFC in the coming days.

--
Gustavo Lopes

11 years ago by Gustavo Lopes — view source

unread

Em 2012-07-18 23:05, Gustavo Lopes escreveu:

Some deficiencies in zpp have been constrai
ning the implementation of common scenarios such as 'allow integer or
NULL'* or the more general 'allow different types for an argument'**.

I've written an RFC. It's available on:

https://wiki.php.net/rfc/zpp_improv

Since there was already a discussion several months ago, I'll move on
an expedited schedule and open the vote next Wednesday, provided that no
new arguments are advanced.

--
Gustavo Lopes

11 years ago by johannes@schlueters.de — view source

unread

Gustavo Lopes glopes@nebm.ist.utl.pt wrote:

I've written an RFC. It's available on:

https://wiki.php.net/rfc/zpp_improv

The patch is mssing an update to README.PARAMETER_PARSING and if you ant to truly export zend_parse_parameter() please mark it as ZENDAPI so it's available from shared extensions and such.

johannes

11 years ago by Lars Strojny — view source

unread

The is_null feature is really helpful. Thanks!

Am 02.01.2013 um 16:26 schrieb Johannes Schlüter johannes@schlueters.de:

Gustavo Lopes glopes@nebm.ist.utl.pt wrote:

I've written an RFC. It's available on:

https://wiki.php.net/rfc/zpp_improv

The patch is mssing an update to README.PARAMETER_PARSING and if you ant to truly export zend_parse_parameter() please mark it as ZENDAPI so it's available from shared extensions and such.

johannes

11 years ago by Ferenc Kovacs — view source

unread

On Wed, Jan 2, 2013 at 3:29 PM, Gustavo Lopes glopes@nebm.ist.utl.ptwrote:

Em 2012-07-18 23:05, Gustavo Lopes escreveu:

Some deficiencies in zpp have been constrai

ning the implementation of common scenarios such as 'allow integer or
NULL'* or the more general 'allow different types for an argument'**.

I've written an RFC. It's available on:

<https://wiki.php.net/rfc/zpp_**improv https://wiki.php.net/rfc/zpp_improv

Since there was already a discussion several months ago, I'll move on an
expedited schedule and open the vote next Wednesday, provided that no new
arguments are advanced.

--
Gustavo Lopes

--

could you please also update README.PARAMETER_PARSING_API in your branch to
match the updated behavior?
thanks!

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

zend_parse_parameters() improvements

I agree that being able to use zpp on single parameter might lead to a cleaner code - we've had some bugs where handmade args parsing was done wrong. So I think this RFC is a good addition.

Cheers,

Cheers,

I agree that being able to use zpp on single parameter might lead to a
cleaner code - we've had some bugs where handmade args parsing was done
wrong. So I think this RFC is a good addition.