Pierre-Alain Joye wrote:
> On Wed, 31 Oct 2001 08:13:28 +0900 Yasuo Ohgaki
<[EMAIL PROTECTED]>
> wrote:
>
>
>> Yasuo Ohgaki wrote:
>>
>>
>>> Sterling Hughes wrote:
>>>
>>>
>>>> I don't know if this has been discussed yet, but while we're
>>>> getting all crazy with breaking compat in 4.1 and/or
>>>> 5.0, why not go ahead and finally fix empty("0") to
>>>> return false, like it really should (a string with 0 in
>>>> it, is *not* imho an empty string).
>>>>
>>>>
>>> $_POST/$_GET/$_COOKIE data has string type by default. It should
>>> return false for empty("0"), I suppose...
>>>
>>
>> Oops. empty('0'). may return TRUE, since $_POST['var'] has string
>> type...
>>
> :)) as I said ;). For post better to use !="" or
isset($_POST['var']);
> if the post vars is empty. And "0" is not an empty string,
> it s a string containing one char (48 ?). If I m not too
> tired the post methods "post" all var even if they are empty.
I agree and I do it that way. (I use !== '', though)
Since PHP is loosely typed language, it just does not matter much
if empty('0') returns false/true. IMO :)
Users need to be more careful upgrading, if this change is made.
Since assigned vars will have string data type unless value is
casted properly. For example,
function foo($int_val) {
// Check '0' or ''
if (empty($int_val)) {
die('Wrong value');
}
else {
// something useful
}
}
$bar = $_POST['some_int'];
foo($bar);
I thought it's a kind of mess fixing these kind of codes. IMHO :)
I think returning true for empty('0') is strange, also.
I'm not opposed to this change.
0 for this :)
--
Yasuo Ohgaki
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
