Em Thu, 19 Jul 2012 20:36:45 +0200, Sara Golemon <poll...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
