All animals are ==, but some animals are === than others.

Equality comparators work differently when it comes to types. Arrays of different instances are always equal (see previous post), objects of different instances are ==-equal but not ===-equal. Funnily, comparing classes (or functions) to strings turns out to be equal again (because identifiers are nothing more than strings ).

<?

$a = array(1,2,3);
$b = array(2,3);

var_dump($a==$b); // false
var_dump($a===$b); // false
array_shift($a); // $a = (2,3)
var_dump($a==$b); // true
var_dump($a===$b); // true (!)

$x = new StdClass();
$y = new StdClass();

var_dump($x == $y); // true
var_dump($x === $y); // false

class X {};

$p = new X();
$q = new X();

var_dump($p == $q); // true
var_dump($p === $q); // false

$r = array();

var_dump($p == $r); // false
var_dump($p === $r); // false

var_dump("X" == X); // true
var_dump("X" === X); // true

Octal or not octal, that's the question

We know hexadecimal representations of numbers in code: 0x00 for example. A less well known number representation are octal numbers. Octal numbers are in C like languages defined by prefixing a number with a 0. This can result in weird bugs, especially when not knowing this format. Not-so-surprisingly PHP adds its special confusing powers to this feature.

     0815===0 = true
      010===8 = true
    "010"==10 = true
     "010"==8 = false
   "010"=="8" = false
  "010"=="10" = true
  "0xf"=="15" = true
    "08"=="0" = false
       018==1 = true
      "01"==0 = false
 "0xf"=="015" = true

Tested with:

<?
function test ($exp) {
 echo sprintf("%15s = %s\n",$exp,eval("return ".$exp.";")?"true":"false");
}

test("0815===0");
test("010===8"); // true
test('"010"==10'); // true
test('"010"==8'); // false
test('"010"=="8"'); // false
test('"010"=="10"'); // true
test('"0xf"=="15"');
test('"08"=="0"');
test('018==1');
test('"01"==0');
test('"0xf"=="015"');

Just another type coercion thingie.

Check this out:

<?
var_dump(1 == "1 dog"); // true
var_dump(1 == "1 cat"); // true
var_dump("1 cat" == "1 dog"); // false

var_dump(1 == "0x1 dog"); // true
var_dump("1 dog" == "0x1 dog"); // false

Result:

bool(true)
bool(true)
bool(false)
bool(true)
bool(false)

Transitivity is none of the things that the "==" operator respects at all. Using the "===" comparator works (in this case). Yet I find this thing funny.

This thing refers to their project as "The key innovation in the 3.0 release is the introduction of the PHP-like Lua".

I would like to point out that this comparison is an awful insult to anyone who uses Lua. I can only assume that the author are not aware of what PHP is at all. Or Lua. Or both.

Identify yourself!

<?
$a = array(1,2,3);
$b = array(1,2,3);

var_dump($a === $b); // true;

$a[] = 4;

var_dump($a === $b); // false

Result:

bool(true)
bool(false)

In other words: You can't check if you have two variables that point to an array are in fact pointing to different arrays or if they are pointing to the same array.

switch your case

<?
switch(0) {
  case "text": var_dump("casejump"); break;
  default: var_dump("default"); 
}

Output is:

casejump

This is so because 0 == "string" is always true because it converts the string to a number, which results in 0.

Java casting mayhem

Wanna cast a Double object to an Integer object? Not sure, but seems like this is the required casting:

(Integer)(int)(double)(Double)somedoubleobject

The (Integer) might be left away however. Well, most often.