Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:31218
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: internals@lists.php.net,stas@zend.com (Stanislav Malyshev)
Date: Mon, 23 Jul 2007 11:03:03 -0700
Message-ID: <20070723110303.0c033048@h4x0r.tss>
In-Reply-To: <46A4DF33.1030403@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>
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 10:02:43 -0700
stas@zend.com (Stanislav Malyshev) wrote:

> I understand why they may want this, but implementing such 
> functionalities opens a very large can of very nasty worms - since 
> libraries start being import-incompatible and then people start making 
> names like Vendor1_Module_Submodule_Exception all over again just to 
> allow their library to be imported with other library.

Once again, you're trying to solve an application problem in the language. It will be the _application_ importing the library, thus is it is up to the _application_ to solve conflicts (i.e., not import everything from both namespaces). Currently, an application can't do anything about name conflicts in libraries short of editing the source; namespaces (assuming the libraries adopt them) give the application that power. That's where the language's responsibility ends.

If there are technical reasons (i.e., compile-time name resolution, as you mentioned in passing), I think it'd be beneficial to see a discussion of those.

A programming language is a tool: a hammer doesn't tell you where to put the nail.

-- 
Andrew Minerd
Software Architect
The Selling Source, Inc.

> > If you use that Vendor1 lib in one.php file a lot you clutter your code 
> > with
> > Vendor1::A, Vendor1::B, Vendor1::C, etc. It is possible to rename Vendor1
> > to something shorter using import but you still have to prefix it.
> 
> I see no problem with Vendor1::A, it's not overly long. When you have 
> Vendor1::A::B::C::D::E then it's long, but you can shorten that. Of 
> course, if you use many different sets with very narrow cross-section it 
> may mean you'd have still to use long names or have a bunch of imports, 
> but putting everything into global space in no way would solve the 
> problem - as I mentioned, good names run out pretty fast, and blanket 
> import means you can never use a plain English word to name any class in 
> your application - because there's a high probability that somebody else 
> would use the same word and thus your library becomes incompatible with 
> his once both are imported. That is on top of a myriad of technical 
> problems that blanket imports bring (think complete impossibility of 
> compile-time name resolution and the trouble of maintaining separate 
> per-file global scopes).
> Also, having a bunch of imports is not that bad if you use a tool - like 
> an IDE - to assist with it.
> 
> > That's why people sometimes want to import *all* names from namespace.
> 
> I understand why they may want this, but implementing such 
> functionalities opens a very large can of very nasty worms - since 
> libraries start being import-incompatible and then people start making 
> names like Vendor1_Module_Submodule_Exception all over again just to 
> allow their library to be imported with other library.