Dennis' note is irrelevant as of today : with last 5.3 builds it is possible to use class names which coincide with PHP's internal class names within your namespaces. His example using PDO now works correctly.
Name resolution rules
Names are resolved following these resolution rules:
-
All qualified names are translated during compilation according to current
import rules. In example, if the namespace A::B::C is imported, a call to
C::D::e()is translated toA::B::C::D::e(). -
Unqualified class names are translated during compilation according to current
import rules (full name substituted for short imported name). In example, if
the namespace A::B::C is imported,
new C()is translated tonew A::B::C(). - Inside namespace, calls to unqualified functions that are defined in the current namespace (and are known at the time the call is parsed) are interpreted as calls to these namespace functions, at compile time.
-
Inside namespace (say A::B), calls to unqualified functions that are not
defined in current namespace are resolved at run-time. Here is how a
call to function foo() is resolved:
- It looks for a function from the current namespace: A::B::foo().
- It tries to find and call the internal function foo().
-
Inside namespace (say A::B), calls to unqualified class names are
resolved at run-time. Here is how a call to
new C()is resolved:- It looks for a class from the current namespace: A::B::C.
- It tries to find and call the internal class C.
- It attemts to autoload A::B::C.
new ::C()has to be used. -
Calls to qualified functions are resolved at run-time. Here is how a call
to A::B::foo() is resolved:
- It looks for a function foo() in the namespace A::B.
- It looks for a class A::B and call its static method foo(). It will autoload the class if necessary.
-
Qualified class names are resolved in compile-time as class from corresponding
namespace. For example,
new A::B::C()refers to class C from namespace A::B.
Example #1 Name resolutions illustrated
<?php
namespace A;
// function calls
foo(); // first tries to call "foo" defined in namespace "A"
// then calls internal function "foo"
::foo(); // calls function "foo" defined in global scope
// class references
new B(); // first tries to create object of class "B" defined in namespace "A"
// then creates object of internal class "B"
new ::B(); // creates object of class "B" defined in global scope
// static methods/namespace functions from another namespace
B::foo(); // first tries to call function "foo" from namespace "A::B"
// then calls method "foo" of internal class "B"
::B::foo(); // first tries to call function "foo" from namespace "B"
// then calls method "foo" of class "B" from global scope
// static methods/namespace functions of current namespace
A::foo(); // first tries to call function "foo" from namespace "A::A"
// then tries to call method "foo" of class "A" from namespace "A"
// then tries to call function "foo" from namespace "A"
// then calls method "foo" of internal class "A"
::A::foo(); // first tries to call function "foo" from namespace "A"
// then calls method "foo" of class "A" from global scope
?>
Name resolution rules
Raphael
26-Mar-2008 07:01
26-Mar-2008 07:01
Will
21-Feb-2008 12:08
21-Feb-2008 12:08
Agreed. Dennis is right on with this. To add on, requiring each file that includes a namespace also defeats the purpose of namespacing. It makes more sense if you have a repository for namespaces and just use those.
Example:
/some/path/to/namespaces/
<?php
use Some::Namespace;
// Test is withing Namespace.
$t = new Test();
// Test2 is not, so it checks includes, etc.
$t = new Test2();
?>
Dennis
04-Jan-2008 03:18
04-Jan-2008 03:18
Sadly enough, the latest class name resolution rules render PHP namespaces quite useless. It is impossible to use class names which coincide with PHP's internal class names within your namespaces unless you _explicitly_ use them and alias them!
The worst thing is that PHP internal class names _always_ will take precedence over your class names. This means that you start developing a toolkit and take good care to use and alias your class names (eg, Exception or DateTime or PDO). You also create classes with names that don't have names that would conflict with PHP's internal classes. However, after you have done lots of work on your toolkit you find out that there's been another extension added to PHP and it has a class that coincides with your class name. Your code becomes useless.
A quick example:
<?php
/*
* (PDO.php)
*/
namespace my::name::space;
class PDO {}
?>
<?php
/*
* (Test.php)
*/
namespace my:name::space;
class Test {
static function doSmth() {
$pdo = new PDO();
}
}
?>
and this code:
<?php
include('PDO.php');
include('Test.php');
use my::name::space::Test;
Test::doSmth();
?>
This of course will emit a warning that PDO constructor expects at least one parameter (which is perfectly correct for PHP Data Objects). Now go to your php.ini and disable lines
extension=php_dll.php
or
extension=pdo.so
as well as all other PDO drivers. Now run the example and it will produce no warnings!
I have used PDO class name here as it can be easily disabled to demonstrate the problem. Now imagine that PDO was not an internal class and you were using it in your code for some time already. Suddenly an extension author choses to use this name. And all your code is broken. You will have to go into every file that references that class and explicitly use it with an alias and rename all occurences of this class name to an alias.
As to me this is too far from solving the name collision issues!
