I agree. If the solution to this is to start adding prefixes to the aliased names, then namespaces lose part of their purpose.
The solution is not to import everything in global space. If you must, namespaces as such won't help you avoid collisions. The purpose of namespaces is *NOT* (I don't know how to make it more clear - should I use blinking text, flash graphics and pictures of dancing girls/boys in bikinis?) - it is *NOT* to allow you shoving all your library classes into global space and in some magic way make same names mean different classes by telepathically reading your mind. The purpose of namespaces is to make working with long names - necessary to avoid collisions - easier, by enabling not always use the whole long name but sometimes only a part of it.
Globbing of this nature, in my humbled opinion, would not be the best idea because of the high potential of problems. But, in the same respect, with
That's *exactly* why it was dropped. More precisely, it is one of the reasons - other being it would break lookup performance and bytecode caches.
I think this is a huge issue, if only for consistency with other constructs of the language. There are already three different ways to write an
Guys, really, how many times should we beat this particular dead horse?
The only difference, on the surface, that I see with namespaces vs. standard prefixing is that namespaces has a new keyword and changes the separator from an underscore to the double colon. Beyond that, without the other
Well, I think reading the actual docs would help to see more. Besides that, namespaces allow aliasing of prefixes and automatic prefixing.
For what it's worth, I would have to completely agree with Derick on this issue. It just seems that namespaces could be made to do much more than it already does.
Leaving braces aside (please!), what capabilities that were not discussed before do you need?
-- 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
