ID: 48012
Updated by: [email protected]
Reported By: dave at ifox dot com
-Status: Open
+Status: Wont fix
Bug Type: Feature/Change Request
Operating System: All
PHP Version: 5.3.0RC1
New Comment:
PHP is first and foremost a Web language, not a general-purpose
scripting language. Since the Web is not typed and everything is a
string, I had to do things slightly differently early on to make PHP do
what people expected. Specifically, "123"==123 needs to be true in
order to not have to type cast every single numeric user input. Given
that, then it also follows that '0'==0 and if you continue with that and
consider that 0==false then it makes sense that '0'==false.
However, '0'===false is, of course, false. This is why we have the
strict type-comparison operators in PHP.
Basically if we change '0' to be true, then we also have to trickle
that change up resulting in '123'!=123 which would break every app out
there. So, while I understand your point, it simply isn't going to
happen.
Previous Comments:
------------------------------------------------------------------------
[2009-04-18 19:05:48] dave at ifox dot com
Description:
------------
PHP Developers,
I typed a very logical explanation of why more careful thought should
have been put into the addition of this conversion:
"0" => FALSE
but the submission failed and so I will try to reproduce it.
When I learned about the exception of the string "0" converting to a
boolean false, I had a sick feeling in my stomach. An entire team of
language developers fell down the slippery slope caused by a handful of
programmers in 2003 and 2004 that wanted to shorten their code, and
thought that "0" -> TRUE was a bug.
Every other language in existence converts a non-empty string to a
boolean TRUE, because they prevail in this logic: the only meaning that
SHOULD be derived from an alphanumeric string is its alphanumeric
content, unless first cast to a numeric (or other) type. For a language
that tries to bring in the best of other languages, PHP should at least
mimic the logical behavior of those languages.
I have edited dozens of web sites to fix well-structured code by
skilled programmers that didn't expect this behavior, particularly when
checking for the existence of strings from databases or user input (form
POSTs). As an example:
if ($_POST["uid"] && ...) { ... }
now must be changed to:
if (strlen($_POST["uid"]) && ...) { ... }
and sometimes there are dozens of these in series. This begs
programmers to be sloppy and just let "0" fail as an unusual case even
when valid as input. And even skilled programmers can't be expected to
read and catch this tiny exception in your documentation.
There are other ramifications from not respecting the alphanumeric
string for the purpose it was intended, to hold alphanumeric values. I
will not expound here. The fact that FORM POSTs yield strings is not
something to streamline in to the assumption that a user "meant" to
enter an integer. Only a beginning programmer wanting a shortcut hack
would expect or want this behavior.
And what of " 0", "0 ", "00", "false", and "0.0"? They are respected!
Originally I thought the "0" conversion was an attempt to make
bool(string(FALSE)) == FALSE, but it already does since string(FALSE) ==
"" (although in other languages, it yields TRUE, because it is
appropriate to conclude that the string representation of any boolean
value has length and is therefore TRUE).
JavaScript, as a common example, understands what an alphanumeric
string is for:
<script>
if ('0') document.write('YES');
</script>
This yields "YES", of course. Unfortunately there are now people out
there posting that JavaScript is broken. But they are beginners, of
course. A language should never make assumptions about a programmer's
users' intent when providing input. If a user intends "0" as a string,
why assume that is a numerical value? Don't you need to now assume all
sorts of zero-value strings?
I have developed two loosely-typed languages, and I made the choice to
treat non-empty strings as TRUE. I find PHP for the web very usable,
but I was completely surprised by this choice, and I'm sorry to say that
it has resulted in high-quality code yielding unexpected subtle failures
for its users.
I modified PHP (14 or so changes in the Zend engine) to remove the
feature and I made a patch. The ill stomach went away, and PHP now
respects alphanumeric strings, but now I am uniquely conscious in a
world of assumptions yielding unexpected results. I guess that's the
beauty and curse of open source.
What were the thought processes in creating this "feature"? Please
consider its removal!
Dave May
Reproduce code:
---------------
$str = "0";
if ($str) echo "TRUE"; else echo "FALSE";
---
>From manual page: language.types.boolean
---
Expected result:
----------------
TRUE
Actual result:
--------------
FALSE
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=48012&edit=1
