After saying it was coming, then delaying it, then people claiming to have gotten it, then those claims being debunked, then some people installing the UK version, TMobile has apparently finally begun shipping the Android 1.5 “Cupcake” update to US G1 owners.

This afternoon, I downloaded and installed the update by hand, a process that took maybe 5 minutes (tops). The instructions claim that there’s a risk of causing damage to your phone (bricking it, most likely); I followed them verbatim and didn’t have any issues.

So far, it’s really good. I doubt I could live without the hardware keyboard, but I was also really annoyed that I had to open the phone to be able to type even the simplest “ok”. The soft-keyboard completely solves that, and while I’m still in the process of calibrating my fingers, it’s worked well enough so far. The suggestions seemed accurate and have already saved me some pecking time.

Other than that, there seem to be a lot of spit and polish updates, and a few new features. The T-Mobile forums have a full list of changes. Since I have iPhone envy, I immediately turned on the screen transitions. I also played briefly with the video recorder, and also just made sure that I can play music through my Bluetooth headphones. I also turned on the auto-rotations, but I’m not sure I’ll keep them.

In short, if you have a G1, I’d say you check out the update now — don’t wait! (But, then, I’m impatient.)

When unserializing an object whose class definition is not present, PHP returns an instance of the special type, __PHP_Incomplete_Class, which issues notices if you attempt to call a method or access a property.

For example, this code produces the following:

andrew@fake:~$ php incomplete.php
object(__PHP_Incomplete_Class)#1 (2) {
  ["__PHP_Incomplete_Class_Name"]=>
  string(4) "test"
  ["name"]=>
  string(2) "hi"
}

Notice: main(): The script tried to execute a method or access a property of an
incomplete object. Please ensure that the class definition "test" of the object you
are trying to operate on was loaded _before_ unserialize() gets called or provide
a __autoload() function to load the class definition  in /home/andrew/test2.php
on line 7
NULL

Interestingly, the is_object method returns false when given an instance of __PHP_Incomplete_Class. This seems to be in contradiction with var_dump (as evidenced above), gettype, and get_class, all of which return values indicating that the incomplete class is a normal object.

This was reported as bug 19842 way back in 2002, but didn’t seem to be considered a problem. (The suggested solution was simply to have all class definitions present before unserializing that object.)

To be fair, this behavior of is_object is documented in the notes section of its manual page. It also appears to be intentional, judging from this section in ext/standard/type.c, determining whether a variable is an object:

   220                          if (!strcmp(ce->name, INCOMPLETE_CLASS)) {
   221                                  RETURN_FALSE;
   222                          }

That said, it’s a little confusing when you first run into it, and means that if you’re examining a session for which you don’t have all the class definitions (writing tools outside of your application, for instance), it’s just a little bit harder to determine which variables within the session are objects.

The workaround, of course, is easy, given that most other methods treat the object as an object: $is_object = (get_class($o) !== FALSE);.

If this isn’t the best PHP bug report ever, it’s definitely in the running.