In reality, it is rarely (almost never) needed to import all the classes. Usually you need 2–4 per file, not more, and importing just what you really need is the step to a clean design.
You don't need to import every class which is used implicitly, only those which are explicitly used. On 7/23/07, Jeremy Privett <[EMAIL PROTECTED]> wrote:
Stanislav, Absolutely not the case. Take a look at C++, C#, even Python. The "namespaces" implementation of those languages is mostly consistent (even if Python doesn't call it that). You're not helping developers at all with this implementation. If you're working with a large library and have to import a lot of classes, the way this works is nothing but a pain. We would be better off not using namespaces at all, in this case. Thus, the problem has not been solved. Also, for the implementation to be complete, Core Developers and Extension Developers would need to namespace their classes / functions. And that, undoubtedly, is a LOT of work. I can understand this being the justification for implementing namespaces in the way it's been implemented, because all of this other stuff in the global namespace, but you still need to offer developers *some* way of importing everything out of a namespace. I absolutely will have upwards to close to 25 - 30 classes in a single namespace. And sometimes more. To be able to import them all is an absolute necessity for this implementation to be remotely feasible. Having an import block at the top of files that's that huge just doesn't make any sense. And that doesn't even consider the fact that I may be using OTHER libraries as well that may be namespaced. PEAR is a perfect example of this. Look at all the libraries that exist there. I would absolutely love to just: import PEAR; import PEAR::HTTP; import PEAR::Image; And not have to worry about going through and picking out every little individual class that I need. And with all of the languages I mentioned before, that is *exactly* how it works. Of course, we're back to the namespacing of the PHP Core and Extensions. Which is really the main blocker to any serious namespaces implementation, beyond what's currently patched to HEAD today, correct? I hope you can better see my viewpoint, now that I actually had the time to sit down and type out a more coherent reply. This implementation and the unicode.semantics discussion have to be the most frustrating points PHP6 has for me, right now. Thanks. --- Jeremy Privett Software Developer Peak8 Solutions -----Original Message----- From: Stanislav Malyshev [mailto:[EMAIL PROTECTED] Sent: Monday, July 23, 2007 1:39 AM To: Jeremy Privett Cc: Derick Rethans; Markus Fischer; internals Subject: Re: [PHP-DEV] Question about Namespace patch > And that's exactly why this implementation isn't intuitive. As far as I > can see from the way it's been explained, so far, that is not possible. No implementation is "intuitive", unless by "intuitive" you mean "works as in that other language I know". Too bad in each of these languages it works differently :) -- 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
-- Alexey Zakhlestin http://blog.milkfarmsoft.com/
