Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:31222
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain sellingsource.com from 208.67.190.52 cause and error)
Date: Mon, 23 Jul 2007 11:28:10 -0700
To: stas@zend.com (Stanislav Malyshev)
Cc: 'PHP Internals' <internals@lists.php.net>
Message-ID: <20070723112810.0428efdd@h4x0r.tss>
In-Reply-To: <46A4EEBA.7040308@zend.com>
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>
Organization: The Selling Source, Inc.
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Question about Namespace patch
From: andrew.minerd@sellingsource.com (Andrew Minerd)

On Mon, 23 Jul 2007 11:08:58 -0700
stas@zend.com (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.