Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
Not entirely correct - namespaces needed to reconcile _multiple_
libraries, while in case of Exception you need to stay away only
from _one_ set of classes - namely, internal ones. While indeed even
that could be inconvenient, the problem is that it is not possible
to avoid ambiguity in all cases successfully, so we had to choose
how we solve ambiguous cases. We decided to solve it in a way that
gives most old code most chance to work, while knowing that some
people would find some code less convenient with any code. Out
solution allows to explicitly specify your intent in one of these
ways:
1. Defining the class
2. Importing the name
I agree with this approach, I just disagree about which set of names
we should require people to import.
say that we are talking about code _inside_ of a namespace. It
would not add much conversion burden to say that if you want to use
global classes in a file you are adding a namespace to, then just
add imports for those classes. If PHP provided a PHP:: namespace
with all global classes in it
I think it would. It is much easier to keep track on your own
classes than on system classes create by somebody else.
I agree and I think this is an excellent reason that external classes
should be imported - that way they are easier to keep track of.
Also, below you say:
If you are OK with writing imports, then it shouldn't matter too
much which imports you write.
I think that goes both ways. I am okay with importing classes outside
of my namespace. It doesn't make sense to me to have to import names
inside my own namespace. And the fact that changes to what classes PHP
provides can change the order of class resolution seems like
unnecessary fragility to me.
I really think people should think about the way their code is
organized when they put it in a namespace. And I really don't think
it's a bad thing if you need to list your external dependencies using
import.
And with exception of Exception (no pun intended :) I think there
would be not many classes that would have names coinciding with
internal class names.
Remember Date? (now DateTime)? This is mostly true right now because
there was no concept of namespacing and only very well organized class
libraries prefixed their classes. When people start moving their code
into namespaces and then taking advantage of that to remove the
prefixing, I think this will be more common.
Also it would cause autoload call on each use of system classes even
if you never had overridden them at all, which can have significant
impact on the performance - exhaustive autoload search can be very
expensive.
I am not understanding why the extra autoload for system classes is
necessary (I do understand why my initial re-ordering of include rules
would cause two autoload calls and I agree that that is an awful idea
now).
- inside a namespace (Foo::), I try to create a new Exception
- if no Foo::Exception class exists, we try to autoload
"Foo::Exception". There is no need to autoload just "Exception".
If what I meant was to create an ::Exception, then I just do import
Exception; inside my namespace and the class exists - no autoload is
necessary.
Am I missing something?
Sincerely,
-chuck
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
