Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
... which is correct as far as it goes, there are no side effects.
However, if I flip the include order, including 1.php before 2.php,
then I get this:
Test::Exception
Test::Exception
Of course, since once Test::Exception is defined, Exception in
namespace Test refers to it. It does not influence imports though.
namespace I have full control over the things inside my namespace.
The way things work right now I either need to list every single
class in my namespace in every file of that namespace - which is
going to be a bit
Of course not - the problem even exists only for those classes that
override internal class names, and only in the context where the
overriding class is not defined but you still want to use it. If you
either explicitly load it or specify full name - it would be OK. And
so far we have one such name - Exception, so telling "every single
class" is a gross overstatement unless your package does nothing but
throwing exceptions :)
Right, it's not going to affect most classes most of the time, but my
point is that you can't predict which classes will be affected.
Exception is just the most obvious example. Looking at the built-in
class list, Directory and DateTime jump out as ones that will probably
come up a lot.
Also looking at the global classes list, it's not that big. I really
don't think importing your external dependencies would be a hardship.
I know Stas gets a lot of weight here because he can write the code
for it. I'd like to know if any other developers have strong feelings
either way, because I can write tests or even (scary as it might be
for others) look at the engine code to change this behavior if that's
the only difference maker.
-chuck
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
