Yes. I think that if you use an unqualified name it should always be
relative to the namespace (and importing internal classes into your
namespace lets you use short names for them, avoiding ::Exception).
Unfortunately, there are problems with this solution, since it
makes common case harder to implement - internal classes are more
frequently used than overridden. It makes harder to convert library code
which does not use tricks like overriding system classes - which is on
my experience most of the code - you have now to go to almost every file
and find all the system classes you have used there and put imports for
them.
To me, this is unpredictable because include order changes how otherwise
identical code behaves.
It is entirely predictable, and you know the rules that would allow you
to predict it.
I can solve this in my case by always writing import Test::Exception;.
However, if I really want to use the builtin Exception class, it seems
like I _must_ type it as ::Exception every time - which is something you
wanted to avoid as well as I.
If you really want to use internal class, why you define and include
non-internal class with the same name? Moreover, your own proposal above
says that's what you have to do - write ::Exception or import. So either
you want unqualified internal names to work or you don't?
Other options I tried:
import Exception;
-> name conflict, which seems correct
import Exception is a no-op, so I don't understand how you could have
got name conflict. Do you mean "import Test::Exception"? That should
work, if it didn't it's a bug.
import Exception as Error;
-> Fatal error: Import name 'Error' conflicts with defined class in
/Users/chuck/Desktop/php namespaces/2.php on line 4
(this I don't understand)
I'm afraid I am missing something since in line 4 of 2.php there's no
definition of any class or import. Can you give me full examples of
non-working parts? It might be there's some bug in there.
import ::Exception as Error;
-> parse error (can't import a top-level class name that way)
Well, we might allow importing global classes, if it's needed.
Therefore, in my mind, in order to write durable code that will not
break no matter what other classes other developers define or import, I
should always prefix builtin classes with ::.
Other developers shouldn't define or import classes into your namespace...
Given this, the only difference between how I think things should work
is that I think that, when I have declared a namespace, I should be able
to rely on any short name referring to that namespace or one of my
explicit imports. The key being that _I_ declared that namespace and the
Well, I think restricting namespaced code's access to internal classes
is not a good idea, since internal classes are rather frequently used.
imports and they will affect only that file, so I am completely in
control of what name means what.
You can control it anyway, you just have to be a bit more explicit now.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
