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
