Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:31226
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 63.205.162.114 as permitted sender)
Message-ID: <46A51D7F.7060206@zend.com>
Date: Mon, 23 Jul 2007 14:28:31 -0700
Organization: Zend Technologies
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: Andrew Minerd <andrew.minerd@sellingsource.com>
CC: 'PHP Internals' <internals@lists.php.net>
References: <46A31D95.2080407@fischer.name>	<E996AAF4A714DF4D9BD59E9418957A2128CD19@peak8sbs.peak8solutions.local>	<46A4661A.6080202@zend.com>	<200707231140.55535.pstradomski@gmail.com>	<46A4BA4F.6090506@dealnews.com>	<40CA6572-030F-43E2-8706-64D1167C527C@bitxtender.com>	<46A4C090.50402@php.net>	<3d1a63d10707230942y2b2504d1p5f995f01d28a622b@mail.gmail.com>	<46A4DF33.1030403@zend.com>	<20070723110303.0c033048@h4x0r.tss>	<46A4EEBA.7040308@zend.com> <20070723112810.0428efdd@h4x0r.tss>
In-Reply-To: <20070723112810.0428efdd@h4x0r.tss>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Question about Namespace patch
From: stas@zend.com (Stanislav Malyshev)

> 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
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com