Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61518
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.213.42 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <op.whpjg0eqidpuyk@damnation>
References: <op.whnt7vdjidpuyk@damnation>
	<CAESVnVq7tCP3oCwgyq1BGz8JmoAGUY1anE_TAe2cZeErKNXCBQ@mail.gmail.com>
	<op.whpjg0eqidpuyk@damnation>
Date: Thu, 19 Jul 2012 14:23:44 -0700
Message-ID: <CAESVnVoTSP-9nXoj1LffgdhXK8L_a7aVbsgy+Z4y9ncku2EVNQ@mail.gmail.com>
To: Gustavo Lopes <glopes@nebm.ist.utl.pt>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d0447850df44fe104c535641e
Subject: Re: [PHP-DEV] zend_parse_parameters() improvements
From: pollita@php.net (Sara Golemon)

--f46d0447850df44fe104c535641e
Content-Type: text/plain; charset=ISO-8859-1

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.pt>wrote:

> 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
>

--f46d0447850df44fe104c535641e--