Then I'm not sure what problem you're trying to solve either. :/
On Thu, Jul 19, 2012 at 12:08 PM, Gustavo Lopes <glo...@nebm.ist.utl.pt>wrote:
> 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
>
