[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 daniel.busc...@nextiraone.eu
To: php-general@lists.php.net
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
