Quoting Stanislav Malyshev <stas@zend.com>:
> This is even better than requiring, and makes the intent very clear.
> I don't think it decreases intuitiveness, on the contrary - from the
> look of the code it is immediately clear which exception would be
> used.
I went ahead and tried to apply this (explicit imports of classes in
the same namespace) to the library that I'm working on, and it doesn't
work. Here's the same example as before with 1.php and 2.php, but this
time we're trying to avoid ambiguity by importing Test::Exception in
each file:
1.php:
------
<?php
namespace Test;
import Test::Exception;
throw new Exception();
2.php:
------
<?php
namespace Test;
import Test::Exception;
throw new Exception();
(yes, they are identical; imagine that one defines, say, Test::Runner
and the other defines Test::Case, both of which can throw
Test::Exception)
Now I run parent.php, which looks like:
---------------------------------------
<?php
function __autoload($class) {
include './test_exception.php';
}
try {
include '2.php';
} catch (Exception $e) {
echo get_class($e) . "\n";
}
try {
include '1.php';
} catch (Exception $e) {
echo get_class($e) . "\n";
}
And I get:
----------
$ php parent.php
Test::Exception
Fatal error: Import name 'Exception' conflicts with defined class in
/Users/chuck/Desktop/php namespaces/1.php on line 4
This one I can't solve by removing the use of autoload, either - if I
include test_exception.php before doing anything, it just fails on the
first file that imports it:
$ php parent.php
Fatal error: Import name 'Exception' conflicts with defined class in
/Users/chuck/Desktop/php namespaces/2.php on line 4
I can go back to avoiding the names of all PHP built in classes like
we had to do before namespaces, but PHP _should_ be able to add new
builtin classes without affecting my code - that should be one of the
biggest benefits of namespaces. And that's not even talking about how
including other non-namespaced code shouldn't be able to affect how my
namespaced code behaves.
-chuck
