# zend_parse_parameters() improvements - Thread: https://externals.io/message/61440 - Original archive: https://news-web.php.net/php.internals/61440 - Started by Gustavo Lopes on 2012-07-18T21:05:45+00:00 - Messages: 26 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/61440.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #61440 — Gustavo Lopes — 2012-07-18T21:05:45+00:00 URL: https://externals.io/message/61440#61440 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 } } -- Gustavo Lopes --- ## #61444 — Nikita Popov — 2012-07-18T22:31:48+00:00 URL: https://externals.io/message/61440#61444 · In reply to: #61440 > 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 --- ## #61448 — Stas Malyshev — 2012-07-18T23:11:38+00:00 URL: https://externals.io/message/61440#61448 · In reply to: #61440 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 --- ## #61450 — Gustavo Lopes — 2012-07-18T23:27:49+00:00 URL: https://externals.io/message/61440#61450 · In reply to: #61448 Em Thu, 19 Jul 2012 01:11:38 +0200, Stas Malyshev escreveu: > > […] > > 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 --- ## #61511 — Sara Golemon — 2012-07-19T18:36:45+00:00 URL: https://externals.io/message/61440#61511 · In reply to: #61440 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 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 > > 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 > } > } > > > -- > Gustavo Lopes --- ## #61513 — Gustavo Lopes — 2012-07-19T19:08:50+00:00 URL: https://externals.io/message/61440#61513 · In reply to: #61511 Em Thu, 19 Jul 2012 20:36:45 +0200, Sara Golemon 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 --- ## #61518 — Sara Golemon — 2012-07-19T21:23:44+00:00 URL: https://externals.io/message/61440#61518 · In reply to: #61513 Then I'm not sure what problem you're trying to solve either. :/ On Thu, Jul 19, 2012 at 12:08 PM, Gustavo Lopes wrote: > Em Thu, 19 Jul 2012 20:36:45 +0200, Sara Golemon > escreveu: > > > For this type of situation, you could equally go with something like: > > […] > > 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: > > […] > 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 --- ## #61519 — Nikita Popov — 2012-07-19T21:33:04+00:00 URL: https://externals.io/message/61440#61519 · In reply to: #61518 > 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 --- ## #61520 — Stas Malyshev — 2012-07-19T21:38:38+00:00 URL: https://externals.io/message/61440#61520 · In reply to: #61519 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 --- ## #61526 — Sara Golemon — 2012-07-19T22:20:49+00:00 URL: https://externals.io/message/61440#61526 · In reply to: #61519 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 > > > […] > > 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 --- ## #61527 — Nikita Popov — 2012-07-19T23:22:38+00:00 URL: https://externals.io/message/61440#61527 · In reply to: #61526 > 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 --- ## #61530 — Gustavo Lopes — 2012-07-19T23:49:50+00:00 URL: https://externals.io/message/61440#61530 · In reply to: #61526 Em Fri, 20 Jul 2012 00:20:49 +0200, Sara Golemon 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 --- ## #61531 — Stas Malyshev — 2012-07-20T00:07:31+00:00 URL: https://externals.io/message/61440#61531 · In reply to: #61530 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 --- ## #61533 — Gustavo Lopes — 2012-07-20T00:29:04+00:00 URL: https://externals.io/message/61440#61533 · In reply to: #61531 Em Fri, 20 Jul 2012 02:07:31 +0200, Stas Malyshev escreveu: > > […] > > 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 --- ## #61536 — Stas Malyshev — 2012-07-20T00:58:12+00:00 URL: https://externals.io/message/61440#61536 · In reply to: #61533 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 --- ## #61539 — Nikita Popov — 2012-07-20T07:26:51+00:00 URL: https://externals.io/message/61440#61539 · In reply to: #61531 > 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 --- ## #61575 — Stas Malyshev — 2012-07-20T16:59:46+00:00 URL: https://externals.io/message/61440#61575 · In reply to: #61539 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 --- ## #61615 — Pierre Joye — 2012-07-21T11:13:23+00:00 URL: https://externals.io/message/61440#61615 · In reply to: #61526 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 --- ## #61619 — Gustavo Lopes — 2012-07-21T12:11:18+00:00 URL: https://externals.io/message/61440#61619 · In reply to: #61615 Em Sat, 21 Jul 2012 13:13:23 +0200, Pierre Joye escreveu: > > > […] > > Fully agreed, if we can avoid the introduction of yet another set of > #ifdef, then I'm all for it. > > > […] > > 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 --- ## #61620 — Pierre Joye — 2012-07-21T12:25:11+00:00 URL: https://externals.io/message/61440#61620 · In reply to: #61619 hi Gustavo, > Em Sat, 21 Jul 2012 13:13:23 +0200, Pierre Joye > escreveu: > > > > […] > > 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 --- ## #64368 — Nikita Popov — 2012-12-19T21:07:16+00:00 URL: https://externals.io/message/61440#64368 · In reply to: #61440 On Wed, Jul 18, 2012 at 11:05 PM, Gustavo Lopes 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 > What's the state of this? Nikita --- ## #64376 — Gustavo Lopes — 2012-12-20T08:27:41+00:00 URL: https://externals.io/message/61440#64376 · In reply to: #64368 Em 2012-12-19 22:07, Nikita Popov escreveu: > On Wed, Jul 18, 2012 at 11:05 PM, Gustavo Lopes > wrote: > > > […] > > Whats the state of this? > I'll try to find the energy to write the RFC in the coming days. -- Gustavo Lopes --- ## #64470 — Gustavo Lopes — 2013-01-02T14:29:37+00:00 URL: https://externals.io/message/61440#64470 · In reply to: #61440 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: 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 --- ## #64471 — johannes@schlueters.de — 2013-01-02T15:26:00+00:00 URL: https://externals.io/message/61440#64471 · In reply to: #64470 Gustavo Lopes wrote: >I've written an RFC. It's available on: > > 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 --- ## #64498 — Lars Strojny — 2013-01-03T11:32:29+00:00 URL: https://externals.io/message/61440#64498 · In reply to: #64471 The is_null feature is really helpful. Thanks! Am 02.01.2013 um 16:26 schrieb Johannes Schlüter : > > > Gustavo Lopes wrote: > > […] > > 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 --- Next page: https://externals.io/message/61440.md?page=2