Re: [PHP] PHP is Zero
Just found out that MySQL uses the same implicit conversion precedence on SQL clauses. That shows me that possibly exists some "higher order" rule that states this consistency, and changing that is outside the scope of PHP. On Thu, Jun 13, 2013 at 9:20 AM, Stuart Dallas wrote: > On 13 Jun 2013, at 12:27, BUSCHKE Daniel > wrote: > > > 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. > > I don't know what the actual reasoning is; if you want that I suggest you > ask on the internals list, but be careful how you phrase the question. If > it's pure curiosity then that's fine, but whether you agree with the > reasoning or not it's gone way past the point where it can be changed. > > My take it that the behaviour is perfectly reasonable. When you compare > two different types it has to convert one of them. If you're comparing a > string to a number it seems logical to me that the number should be the > preferred type, so the string gets converted. What would you expect > array(5) == 5 to give you? Would you expect the 5 to be converted in to an > array? No. The reason it looks odd for "PHP" == 0 is that there's no reason > why the 0 should not be converted to "0", except that strings and numbers > are not the only types available and there has to be an order of > precedence. And consistency is key. > > As for how strings get converted to numbers I have no idea why it will > take everything up to the first non-e|E|. character. The documentation[1] > simply states the behaviour and doesn't go in to why. However, I have to > ask why it matters? Why would you want to convert > '8315e839da08e2a7afe6dd12ec58245d' to an integer? If you have code that's > juggling it automatically, be more explicit. It's fine to be interested in > the reasons why it does what it does, but if it's causing you problems then > the issue is with your code not being explicit enough, not PHP. > > -Stuart > > [1] http://php.net/language.types.string#language.types.string.conversion > > -- > Stuart Dallas > 3ft9 Ltd > http://3ft9.com/ > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP] PHP is Zero
On 13 Jun 2013, at 12:27, BUSCHKE Daniel wrote: > 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. I don't know what the actual reasoning is; if you want that I suggest you ask on the internals list, but be careful how you phrase the question. If it's pure curiosity then that's fine, but whether you agree with the reasoning or not it's gone way past the point where it can be changed. My take it that the behaviour is perfectly reasonable. When you compare two different types it has to convert one of them. If you're comparing a string to a number it seems logical to me that the number should be the preferred type, so the string gets converted. What would you expect array(5) == 5 to give you? Would you expect the 5 to be converted in to an array? No. The reason it looks odd for "PHP" == 0 is that there's no reason why the 0 should not be converted to "0", except that strings and numbers are not the only types available and there has to be an order of precedence. And consistency is key. As for how strings get converted to numbers I have no idea why it will take everything up to the first non-e|E|. character. The documentation[1] simply states the behaviour and doesn't go in to why. However, I have to ask why it matters? Why would you want to convert '8315e839da08e2a7afe6dd12ec58245d' to an integer? If you have code that's juggling it automatically, be more explicit. It's fine to be interested in the reasons why it does what it does, but if it's causing you problems then the issue is with your code not being explicit enough, not PHP. -Stuart [1] http://php.net/language.types.string#language.types.string.conversion -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP is Zero
On 13/06/13 08:59, BUSCHKE Daniel wrote: 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? :) 42 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) Since PHP is a weakly-typed language, it has to choose one way or the other. The behaviour *is* predictable if you know what the rule is (I'm sure the order of conversion is documented somewhere). 3. Why is PHP throwing data away which has the developer explicit given to the interpreter? Because PHP is weakly-typed, the developer is not being sufficiently explicit. Try php -r 'var_dump(intval('PHP') == 0);' and php -r 'var_dump('PHP' == strval(0));' to see explicit code. Anything less is implicit. 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? The rule is consistent: it always converts the string to an integer whatever the order. 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) 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. The weak typing *is* a feature of PHP: other languages are more suitable when you need more enforcement of types: Java, for example. With all due respect to an experience programmer, years of experience do not make up for a limited tool set. Best Regards Daniel Buschke Cheers Pete -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
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