All of these do exactly the same: set a property X on object window.

But, when it comes to iterating window properties in IE (surprise), there seems to be a difference between the first two assignments and the last two. The code for iterating is simple; it iterates through all of the window’s properties and alerts if X is found.

With the first two assignments (the ones that write explicitly to window), the property shows up, but with the last two (where properties are implicitly assigned to window), it doesn’t. It works in Firefox, Opera, Chrome, Safari, but not in IE (not even in IE8). You can try it out here.

Why this is so, I can only guess. The property obviously exists, because window['X'] and window.X always contain the correct value. One possibility is that iterating over object properties in IE doesn’t iterate over the properties that object actually owns, but rather over a separate collection of property names. This separate collection isn’t updated properly when variables are assigned to the window object implicitly. Another possibility is that such variables exist in a global closure, and as such aren’t true members of the window object. When you access window.X and if it doesn’t exist, it’s looked up in that closure.

Interesting if not life-changing stuff. Maybe I’ll do some more research on this.

Helper functions:

function write_obj($obj)
{
  file_put_contents('obj.data', serialize($obj));
}

function read_obj()
{
  return unserialize(file_get_contents('obj.data'));
}

Example 1
Serializing an object with a public property.

class X
{
  public $a = 'A';
}
obj_write(new X());

read.php declares a blank class.

class X
{
}
$x = obj_read();
print_r($x);
echo $x->a

As you might expect, the public property is restored correctly:

X Object
(
    [a] => A
)
A

Example 2
Adding some protected properties.

class X
{
  public $a = 'A';
  protected $b = 'B';
  protected $c = 'C';
}
obj_write(new X());

read.php declares only one protected variable $c.

class X
{
  protected $c;
}
$x = obj_read();
print_r($x);
echo $x->a;
echo $x->b;
echo $x->c;

An this is the result:

X Object
(
    [c:protected] => C
    [a] => A
    [b:protected] => B
)
A
Notice: Undefined property: X::$b in /home/gasper/phpser/test1-read.php on line 12
Fatal error: Cannot access protected property X::$c in /home/gasper/phpser/test1-read.php on line 13

As you see, print_r correctly prints out the object. Properties $b and $c are both protected. What differs is that when printing out $x->b, PHP reports that $b is undefined property, and it correctly throws a Fatal when accessing $c. The question is, why doesn’t the fatal error already occur when accessing $b? As you can see from print_r output, property $b is present in the $x, and it’s correctly marked as protected, just as is $c. The only difference here is that $b isn’t declared in the class definition, so I guess PHP checks the class definition when accessing properties, rather than actual object information.

Example 3
Now let’s twist up things some more by modifying X definition in read.php:

class X
{
  public $c;
  function getB()
  {
    return $this->b;
  }
  function getC()
  {
    return $this->c;
  }
}
print_r($x);
echo "a: " . $x->a;
echo "b: " . $x->b;
echo "c: " . $x->c;
echo "getB: " . $x->getB();
echo "getC: " . $x->getC();

As you can see, I’ve changed $c visibility to public, and I’ve written two getters. The former is a test whether I can shift visibility of $c upon unserializing, while the second will hopefully allow me to read the variables $b and $c, which are protected in the original definition, and not declared in this one.

Here’s the output:

X Object
(
    [c] =>
    [a] => A
    [b:protected] => B
    [c:protected] => C
)
a: A
Notice: Undefined property: X::$b in /home/gasper/phpser/test1-read.php on line 20
b: c:
Notice: Undefined property: X::$b in /home/gasper/phpser/test1-read.php on line 9
getB:
getC:

The first strange thing is that there are two $c properties declared; one protected and one public. While this might be expected (the serialized information specifically tells PHP to unserialize a protected variable $c), it’s still strange that I now have two variables named $c. I don’t think this is possible to achieve without serialization. If you subclass a class and shift visibility of a variable from private/protected to protected/public, you still only have one single variable, so this behavior may come as unexpected. Still, the $x->c and getC() both return an empty value, because no value for public $c was present in the serialized object.

The other thing is that I still can’t access $b, even through a getter. The property is obviously present in the object (as print_r shows), but even when accessing it through a getter, which has access to instance’s protected variables, PHP reports that it’s undefined. I can’t think of a reasonable explanation for that, but this again shows that care should be taken when serializing objects.

Conclusion
As stated before, serializing and unserializing objects with different versions of classes can be a cause for a lot of trouble. If your classes rarely change, or if you have some means of invalidating the serialized objects (ie flushing the cache, or rewriting the rows in the database), then you’re probably fine, although you should always be aware of possible consequences. Likewise, if you cache object with public properties only, these seem to work fine, whether they’re declared or not.

But if you have classes that change often or rely heavily on persistent storage of serialized objects, you should use another way of doing it. One way I can think of is reading the written object with the old version of the class, and passing them to another script/service, which writes them in the new format. This is possible to achieve, but is quite volatile. Other means include using XML to store persistent object data, perhaps even JSON. In these cases, you don’t store the object itself, just as with serialization, but a subset of its properties that are essential to restoring it correctly. Upon recreating the object, these properties are read one by one into a blank object of a proper class version.

So, that’s it. Take care with serialization!