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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
