Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61513
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.21 cause and error)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: "Sara Golemon" <pollita@php.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
References: <op.whnt7vdjidpuyk@damnation>
 <CAESVnVq7tCP3oCwgyq1BGz8JmoAGUY1anE_TAe2cZeErKNXCBQ@mail.gmail.com>
Date: Thu, 19 Jul 2012 21:08:50 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Organization: =?utf-8?Q?N=C3=BAcleo_de_Eng=2E_Biom=C3=A9di?=
 =?utf-8?Q?ca_do_I=2ES=2ET=2E?=
Message-ID: <op.whpjg0eqidpuyk@damnation>
In-Reply-To: <CAESVnVq7tCP3oCwgyq1BGz8JmoAGUY1anE_TAe2cZeErKNXCBQ@mail.gmail.com>
User-Agent: Opera Mail/12.50 (Linux)
Subject: Re: [PHP-DEV] zend_parse_parameters() improvements
From: glopes@nebm.ist.utl.pt ("Gustavo Lopes")

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