Hi, On Fri, Sep 7, 2012 at 2:49 AM, Yahav Gindi Bar <g.b.ya...@gmail.com> wrote: > 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...
The reason why this is not implemented is simple, and it's not to avoid hard-to-read code or "by design". It is a purely technical limitation of the way PHP handles classes/namespaces: When importing a namespace, PHP may have no idea of the classes contained in that namespace. So when you do use Foo\Bar as Gee; PHP have no idea what Foo\Bee really is, whether it is a namespace itself or a class. Nothing might be loaded at that time. *All* it knows is that it needs to substitute occurrences of "Gee" with "Foo\Bar", that's it. Now of course, this wouldn't work with wildcard imports, because if you do: use Foo\*; use Bar\*; new Plop; Even though Plop might only be contained in one of those namespaces, PHP does not necessarily know, and it doesn't know whether to try \Plop, Foo\Plop, or Bar\Plop. This problem is of course non-existent in other languages supporting wildcard imports, because the set of imported classes is finite and well known, which means that conflicts can be detected right away. Best, -- Etienne Kneuss -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
