I am well aware of the === operator, but I had an uneasy feeling that there was still a
trap. However when I tried it it worked, so I was going to thank you for your suggestion,
though I find the concept of having separate 'sort of equal' and 'truly equal' operators
decidedly distasteful, but then I discovered that if you have:
$a = 2260; $b = 226e1; $c = 2.26e3; $d = 2260.0;
$a==$b==$c==$d,
and
$b===$c===$d
Granted $c & $d are less likely to be encountered by accident, but if I want to be certain
the two strings match I will have to stick to the (string) cast or use strcmp. Perhaps we
need a 'really & truly equal' operator ====!
Clancy
>
>And then you discover ===
>
>$i = 0; $j = count ($names); while ($i < $j)
>{ if ($names[$i] === $target) { break; }
>++$i;
> }
>
>... regards
>
>> To: php-general@xxxxxxxxxxxxx
>> From: clancy_1@xxxxxxxxxxxx
>> Date: Sat, 3 Oct 2009 21:21:00 +1000
>> Subject: A really wacky design decision
>>
>> Daevid Vincent is surprised that:
>>
>> $num = 123;
>> $num = $num++;
>> print $num; //this prints 123 and not 124 ?!!
>>
>> To me this is relatively logical. As I understand it, the post-increment operator says "do
>> something with the variable, and then increment it. The trouble in this case is that we
>> are doing something irrational; we are copying the number back to itself, and to me it is
>> reasonably logical (or at least no less illogical than the alternative) to assume that if
>> we copy it to itself, then increment the original version, the copy will not be
>> incremented.
>>
>> However there is one feature of PHP which, to my mind, is really bad design. How many of
>> you can see anything wrong with the following procedure to search a list of names for a
>> particular name?
>>
>> $i = 0; $j = count ($names); while ($i < $j)
>> { if ($names[$i] == $target) { break; }
>> ++$i;
>> }
>>
>> As long as the names are conventional names, this procedure is probably safe to use.
>> However if you allow the names to be general alphanumeric strings, it is not reliable. One
>> of my programs recently broke down in one particular case, and when I eventually isolated
>> the bug I discovered that it was matching '2260' to '226E1'. (The logic of this is: 226E1
>> = 226*10^1 = 2260).
>>
>> I agree that I was well aware of this trap, and that I should not have used a simple
>> comparison, but it seems to me to be a bizarre design decision to assume that anything
>> which can be converted to an integer, using any of the available notations, is in fact an
>> integer, rather than making the default to simply treat it as a string. It is also a trap
>> that it is very easy to fall into if you start off thinking about simple names, and then
>> extend (or borrow) the procedure to use more general strings.
>>
>> And can anyone tell me whether, in the above case, it is sufficient to write simply:
>> if ((string) $names[$i] == $target),
>>
>> or should I write:
>> if ((string) $names[$i] == (string) $target)?
>>
>> (I decided to play safe and use strcmp ().)
>>
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
>_________________________________________________________________
>Windows Live: Keep your friends up to date with what you do online.
>http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_1:092010
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
