note 66173 deleted from language.types.boolean by colder
| From: | colder@php.net | Date: | Tue, 17 Oct 2006 18:48:55 +0000 |
| Subject: | note 66173 deleted from language.types.boolean by colder | ||
| References: | 1 | Groups: | php.notes |
| Request: | Send a blank email to php-notes+get-118660@lists.php.net to get a copy of this message | ||
Note Submitter: alex dot baldacchino at email dot it
----
About bnab at southphlattewebdesign dot com concern, I think that's globally a casting and
backward compatibility matter: as this manual states, a boolean TRUE is converted to string
"1" and this is meaningful being the number 1 a - let's say - "historical"
true value, while a FALSE value is converted to an empty string for some reason (I guess that may be
for concatenation reason or because of an internal representation of strings with the empty string
as the first/main false value and the non empty "0" string being a sort of
legacy/completness secondary false value).
This is the echo behaviour with boolean types, but let's note that boolean type have been
introduced in php 4, while the preg_match function was introduced previously, in php 3.0.9, so
it's returned type is integer and possible results are 0 for false and 1 for true (being this a
"historical", or if preferred "(ANSI) C-like" convention), so in this case the
echo function is not yet converting a boolean value to a string, but a number to a string, and
number convertion rules applies. In order to preserve compatibility with such a convention, a
numerical value of 0 is interpreted as a boolean false in a, let's say, boolean context, as
well as the string "0", so to have a correct 0 (number) -> "0" (string) ->
false (boolean) -> 0 (number, again) conversion.