Re: [PHP] PHP is Zero

2013-06-13 Thread Samuel Lopes Grigolato
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

2013-06-13 Thread Stuart Dallas
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

2013-06-13 Thread Pete Ford

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

2013-06-13 Thread georg

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