Re: Question about Namespace patch

On Mon, 23 Jul 2007 10:02:43 -0700 stas@zend.com (Stanislav Malyshev) wrote: > I understand why they may want this, but implementing such > functionalities opens a very large can of very nasty worms - since > libraries start being import-incompatible and then people start making > names like Vendor1_Module_Submodule_Exception all over again just to > allow their library to be imported with other library. Once again, you're trying to solve an application problem in the language. It will be the _application_ importing the library, thus is it is up to the _application_ to solve conflicts (i.e., not import everything from both namespaces). Currently, an application can't do anything about name conflicts in libraries short of editing the source; namespaces (assuming the libraries adopt them) give the application that power. That's where the language's responsibility ends. If there are technical reasons (i.e., compile-time name resolution, as you mentioned in passing), I think it'd be beneficial to see a discussion of those. A programming language is a tool: a hammer doesn't tell you where to put the nail. -- Andrew Minerd Software Architect The Selling Source, Inc. > > If you use that Vendor1 lib in one.php file a lot you clutter your code > > with > > Vendor1::A, Vendor1::B, Vendor1::C, etc. It is possible to rename Vendor1 > > to something shorter using import but you still have to prefix it. > > I see no problem with Vendor1::A, it's not overly long. When you have > Vendor1::A::B::C::D::E then it's long, but you can shorten that. Of > course, if you use many different sets with very narrow cross-section it > may mean you'd have still to use long names or have a bunch of imports, > but putting everything into global space in no way would solve the > problem - as I mentioned, good names run out pretty fast, and blanket > import means you can never use a plain English word to name any class in > your application - because there's a high probability that somebody else > would use the same word and thus your library becomes incompatible with > his once both are imported. That is on top of a myriad of technical > problems that blanket imports bring (think complete impossibility of > compile-time name resolution and the trouble of maintaining separate > per-file global scopes). > Also, having a bunch of imports is not that bad if you use a tool - like > an IDE - to assist with it. > > > That's why people sometimes want to import *all* names from namespace. > > I understand why they may want this, but implementing such > functionalities opens a very large can of very nasty worms - since > libraries start being import-incompatible and then people start making > names like Vendor1_Module_Submodule_Exception all over again just to > allow their library to be imported with other library.