On Mon, 23 Jul 2007 11:08:58 -0700
[EMAIL PROTECTED] (Stanislav Malyshev) wrote:

> Exactly - not import everything from namespaces. That's what we are doing :)

Well, first of all, not exactly. I think you meant: not import everything from 
two or more namespaces with conflicting names. Secondly, that's not the only 
solution. You could import everything from one, and not import from the other 
(or use a shorter prefix). Thirdly, you're not preventing collisions _at all_:

import Zend::DB;
import My::DB;
import Woot::Database as DB;

And what of applications that use libraries without any conflicting names? 
Let's just be honest about what you're saying: this patch is _intentionally 
crippled_.

> Actually, they can and they do - they use long names which have high 
> chance to be unique. This works, but this is extremely ugly and 
> inconvenient to work with.

The application does? No: the library does. Currently, an application that is 
using two libraries with conflicting names can do nothing to resolve the 
conflicts. With namespace imports (barring a namespace collision), the 
application chooses how it's going to reference the names within a given 
library.

> Allowing blanket imports means we don't know what "new Foo()"
> means until it is executed

No: that comes from applying imports at run-time. A "blanket" import could only 
be applied to classes available at compile time. Granted, that'd be somewhat 
confusing, but, at the very least, address the proper issue.

> That's only one problem with blanket imports.

So..... What are the others?

Andrew Minerd
Software Architect
The Selling Source, Inc.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to