On Fri, Sep 7, 2012 at 3:41 AM, Stas Malyshev <smalys...@sugarcrm.com>wrote:
> Hi! > > > How about adding ability to import the entire namespace? > > This option was explicitly excluded because this defeats the whole idea > of having namespaces - i.e. having names to live in different spaces - > by explicitly bringing unknown set of names into global space. If you > allow global import, then you do not know which any of the names comes > from - it can come from any of the set of imported namespaces, or be > just global - and you have absolutely no idea about it and no way to > avoid conflicts. And all that to save you three keystrokes so you could > write DbConnection and not Db\DbConnection? Definitely not a good idea. > Current implementation makes it clear where things come from and avoids > naming conflicts, while still allowing you to use short names instead of > long and painful ones. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > That's true, but we do got the ability to import only one class from given namespace and classes aliasing so we can, for example, do something like: namespaceClasses.php namespace MyNamespace; class Foo { } class Bar { } class Baz { } use \MyNamespace\* { Foo as F Bar as B }; Then - the Foo and Bar classes will be F and B while Baz and any other class remain Baz. I do understand the point of conflicts, but I think that we should give the programmer the ability to decide whether to import specific class or the entire namespace. Other option I've thought of is to declare rules for importing as keywords or even a function that can import the namespace with given conflict rules for example use \MyNamespace\* noconflict; or even import_namespace('\MyNamespace', NS_AVOID_CONFICT); or something like that, though I think that a keyword allocated only to that propose is definitely not good approach...
