Well, first of all, not exactly. I think you meant: not import
everything from two or more namespaces with conflicting names.
No, not import everything from any namespaces at all, because enabling
it brings more problems than use and is totally unnecessary.
Thirdly, you're not preventing collisions _at all_:
import Zend::DB; import My::DB; import Woot::Database as DB;
This should give an error, just as duplicate class or function
definition does. If it doesn't right now, it should be fixed.
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_.
I am honest and it is not crippled. There is a functionality that does
more harm than good (e.g. - ability to access random memory address) and
so this patch does not provide it.
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.
I'm afraid you lost me here. What exactly application is supposed to do?
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.
You can't imagine how broken that would be - since many classes can be
resolved at compile or run-time based on dependencies to other classes,
load order, config values, etc. which can in turn be based on
dependencies on yet another things. So you'd have absolutely no way to
know _what_ you are importing and you'll be constantly bitten by changes
in totally unrelated code which will break your imports since some class
once was resolved compile-time and now is runtime-loaded or vice versa,
or somebody changed load order in some unrelated files.
On top of that, most PHP programmers have no idea about this whole
compile/runtime class definition thing, so trying to explain them why
their class failed to import would not be an easy task. And PHP is
supposed to be easy. I can describe current model in general in about 4
lines. Can you describe yours?
That's only one problem with blanket imports.
So..... What are the others?
Polluting global space. Unfriendliness to bytecode caches - note that if
you resolve names while compiling file and allow to import without
specifying what exactly are the names you are importing it means now the
current file code depends on each and every file that belongs to the
namespace, and if you add another file to the namespace you'd have to
rebuild all files that ever imported this namespace.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
