Stubblog

So I put down this namespace examples together last night. But, what's happening in the examples regarding to resolution rules? (I won't post the code here again, have a look at the last entry for the example code.)

Version 1 and 2 two are the same, the place where we include other code does not influence naming rules in the current file. Why do we get instances of PHP's internal DateTime class instead of the one from Name::Space? Well, two things have to be considered:
1. We are in the global space, PHP will only look for DateTime in the global space.
2. The use-Statement declares that we want to create a shortcut to Name::Space, not to Name::Space::DateTime. If we wanted to use the class from Name::Space we would need to write $d = new Space::DateTime, which is version 3.
(We can not do a use Name::Space::DateTime here, this results in a fatal error. However, we could do use Name::Space::DateTime as DT and then write $d = new DT(), this will give instances of Name::Space::DateTime.)

With version 4 we have put our example code into its own namespace, but the result is still the same as in version 1 and 2. What's happening?
1. We are in namespace foo, and in namespace foo no class DateTime exists.
2. Our shortcut use Name::Space still does not refer to Name::Space::DateTime, to create instances from this class we still need to write $d = new Space::DateTime as in version 5. This means the class does not apply either in version 4.
3. As no further use declarations exist, PHP falls back to its internal DateTime class. (If this class would not exist, a call to the registered autoload function would be issued.)

Finally, version 6 gives the result we originally intended: The class Name::Space::DateTime is used instead of PHP's internal class. This is because we stated in the use declaration that we want to use Name::Space::DateTime as DateTime.

However, in the original posting of David Zülke in php internals he feared that the two instances of $d might be from different classes. Well, this might really happen under some circumstances. More after the break... Continue reading "Tricky namespaces? No."

Today on php-internals David Zülke posted an interesting example with namespaces which made me think about the result of the small example. Well, my first guess was not right as my experiments showed. Therefore I tried different versions of the example to see the impact of namespace and use declarations. But first, the example:

Name/Space/DateTime.php namespace Name::Space; class DateTime {} Name/Space/Ship.php namespace Name::Space; class Ship { public static function __autoload($className) { echo "loading $className\n"; // ... autoloader, can load Name::Space::DateTime } } somestuff.php function someStuffWeDoNotHaveControlOver() { $foo = new Name::Space::DateTime(); var_dump($foo); // ... } setup.php require_once('Name/Space/Ship.php'); spl_autoload_register(array('Name::Space::Ship', '__autoload'));

Version 1, the original from David's posting:
require_once('setup.php'); use Name::Space; $d = new DateTime(); var_dump($d); require_once('somestuff.php'); // assumed to be here, was missing in the given example someStuffWeDoNotHaveControlOver(); $d = new DateTime(); var_dump($d);

Result:

object(DateTime)#1 (0) {

}

loading Name::Space::DateTime

object(Name::Space::DateTime)#2 (0) {

}

object(DateTime)#2 (0) {

}

More after the break... Continue reading "Tricky namespaces"