[PHP] PHP is Zero
Hi all,
I want to start a discussion about a PHP behaviour that drives me crazy for
years. For the beginning I would like you to guess what the result of the
following snippet will be:
var_dump('PHP' == 0);
I know the difference of == and === but the result was unexcpected for me. And
I hope it is also for you. The result is simply "true". Why is it true? I guess
this happens because of the conversion from 'PHP' to a number which will be 0
in PHP. And of course 0 equals 0. There are several points that I just want to
drop into this mailinglist to discuss about:
1. Why? :)
2. Why is PHP converting the String into a Number instead of converting the
Number into a String? (If my guess concerning the behaviour is correct)
3. Why is PHP throwing data away which has the developer explicit given to the
interpreter?
4. Why does var_dump(0 == 'PHP'); has the same result as the snippet above?
This meens that the equal operator is not explictly implemented in the string
or integer?
5. Thats a bug I have opend: https://bugs.php.net/bug.php?id=51739 where I also
had the same problems because "8315e839da08e2a7afe6dd12ec58245d" was converted
into float(INF) by throwing everything starting from "da08.." away.
I am using PHP since the year 2000. This means I have 13 years of experience in
PHP and I really would like you to NOT just answer "works as designed". I know
it works as designed but I want to discuss the design. Also I know that the
"fuzzy" behaviour of type conversion is a main feature of PHP. I guess this is
one point which makes PHP that successfull. But - in my opinion - the described
behaviour is to fuzzy and just confuses developers.
Best Regards
Daniel Buschke
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP] PHP is Zero
Hi,
I used 2 x =. Using 3 x = would not result in that behaviour because string is
not equal to number. I am fine === here. I explicitly talk about the 2 x =
variant.
BTW:
# php -r 'var_dump("PHP" == 0);'
bool(true)
# php -r 'var_dump("PHP" == 1);'
bool(false)
regards
Daniel
-Ursprüngliche Nachricht-
Von: georg [mailto:georg.chamb...@telia.com]
Gesendet: Donnerstag, 13. Juni 2013 10:35
An: BUSCHKE Daniel
Cc: php-general@lists.php.net
Betreff: Re: [PHP] PHP is Zero
Sorry missed to post list as well
> Hi Daniel,
> here is wild goose
>
> i assume you have 3 x =
> in your "problem" formulation
> which could possibly result in the akward standard C mixup; the
> rightmost = first parsed and resulting in an ASSIGMENT to the variable
> with that value, the comes the parsing of == which is the equivalence
> test, and see; the variable is the same since it was just assigned
> that value; if this theory is correct you would get TRUE regardless
> what number is following :) /g
>
> - Original Message -
> From: "BUSCHKE Daniel"
> To:
> Sent: Thursday, June 13, 2013 9:59 AM
> Subject: [PHP] PHP is Zero
>
>
>> Hi all,
>> I want to start a discussion about a PHP behaviour that drives me
>> crazy for years. For the beginning I would like you to guess what the
>> result of the following snippet will be:
>>
>> var_dump('PHP' == 0);
>>
>> I know the difference of == and === but the result was unexcpected
>> for me. And I hope it is also for you. The result is simply "true".
>> Why is it true? I guess this happens because of the conversion from
>> 'PHP' to a number which will be 0 in PHP. And of course 0 equals 0.
>> There are several points that I just want to drop into this
>> mailinglist to discuss
>> about:
>>
>> 1. Why? :)
>> 2. Why is PHP converting the String into a Number instead of
>> converting the Number into a String? (If my guess concerning the
>> behaviour is
>> correct)
>> 3. Why is PHP throwing data away which has the developer explicit
>> given to the interpreter?
>> 4. Why does var_dump(0 == 'PHP'); has the same result as the snippet
>> above? This meens that the equal operator is not explictly
>> implemented in the string or integer?
>> 5. Thats a bug I have opend: https://bugs.php.net/bug.php?id=51739
>> where I also had the same problems because "8315e839da08e2a7afe6dd12ec58245d"
>> was converted into float(INF) by throwing everything starting from
>> "da08.." away.
>>
>> I am using PHP since the year 2000. This means I have 13 years of
>> experience in PHP and I really would like you to NOT just answer
>> "works as designed". I know it works as designed but I want to
>> discuss the design. Also I know that the "fuzzy" behaviour of type
>> conversion is a main feature of PHP. I guess this is one point which
>> makes PHP that successfull. But - in my opinion - the described
>> behaviour is to fuzzy and just confuses developers.
>>
>> Best Regards
>> Daniel Buschke
>>
>> --
>> PHP General Mailing List (http://www.php.net/) To unsubscribe, visit:
>> http://www.php.net/unsub.php
>>
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP] PHP is Zero
Hi,
thanks for your answer. Especially the answer "42" made me laughing :)
My "Why" questions should be understand as "Why must it be like that" questions.
>> On 13/06/13 08:59, BUSCHKE Daniel wrote:
>> 5. Thats a bug I have opend: https://bugs.php.net/bug.php?id=51739 where I
>> also had the same problems because "8315e839da08e2a7afe6dd12ec58245d" was
>> converted into float(INF) by throwing everything starting from "da08.." away.
>>
> That's a very different proposition, and probably has more to do with word
> size: float is 32-bit, so only the first 32 bits are used and if anything
> else is found the conversion falls back to INF. To handle really big integers
> like 8315e839da08e2a7afe6dd12ec58245d you probably need a more specialist
> library (or language)
For me it is not. PHP throws things away during conversion. In my opinion a
language (compiler, interpreter whatever) should not do that. Never ever!
Either it is able to convert the value or it is not.
What about of returning "null" instead of "0" if the conversion is not perfect?
So intval('F') could return NULL and intval('0') could return 0.
Regards
Daniel
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
AW: AW: [PHP] PHP is Zero
Hi, > It gives up when it finds a non-numeric character (as the documentation would > tell you) Why is PHP doing that? I know it works as designed and I know it is documented like this but that does not mean that it is a good feature, does it? So lets talk about the question: Is that behaviour awaited by PHP software developers? Is that really the way PHP should work here? May we should change that?! BTW: I talked to some collegues and friends since my first post. They all guessed that "'PHP' == 0" is false within a few seconds. I think the weak-typed-PHP is a little to weak at this point. Regards Daniel -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
AW: AW: [PHP] PHP is Zero
To be more technical:
If intval('8315e839da08e2a7afe6dd12ec58245d') would return NULL instead of 8315
then PHP would be still weak-typed and the developer could know that the
conversion failed. Good idea? Of course NULL should be transparent in
operations like +. So 0 + NULL should be still 0.
Regards
Daniel
-Ursprüngliche Nachricht-
Von: BUSCHKE Daniel
Gesendet: Donnerstag, 13. Juni 2013 13:28
An: 'Pete Ford'; php-general@lists.php.net
Betreff: AW: AW: [PHP] PHP is Zero
Hi,
> It gives up when it finds a non-numeric character (as the documentation would
> tell you)
Why is PHP doing that? I know it works as designed and I know it is documented
like this but that does not mean that it is a good feature, does it? So lets
talk about the question: Is that behaviour awaited by PHP software developers?
Is that really the way PHP should work here? May we should change that?!
BTW: I talked to some collegues and friends since my first post. They all
guessed that "'PHP' == 0" is false within a few seconds. I think the
weak-typed-PHP is a little to weak at this point.
Regards
Daniel
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
