Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40480
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 208.83.222.18 cause and error)
Message-ID: <48C9F44B.7020008@chiaraquartet.net>
Date: Thu, 11 Sep 2008 23:47:07 -0500
User-Agent: Thunderbird 2.0.0.16 (X11/20080724)
MIME-Version: 1.0
To: Stan Vassilev | FM <sv_forums@fmethod.com>
CC: internals@lists.php.net
References: <EDD81B0D532744D4A80E7AFA2AA377FE@pc>
In-Reply-To: <EDD81B0D532744D4A80E7AFA2AA377FE@pc>
Content-Type: text/plain; charset=windows-1251
Content-Transfer-Encoding: 7bit
Subject: Re: Scoping of "use" statements and a strategy for 5.3/6.0 release
 of namespace
From: greg@chiaraquartet.net (Gregory Beaver)

Hi Stan,

I realized I missed 2 of your points, response below:

Stan Vassilev | FM wrote:
> Hi,
> 
> Multiple namespaces per file were introduced to allow certain
> workflows in PEAR and frameworks like Symphony which can combine
> multiple classes and namespaces in a single package.
> 
> They work like this:
> 
> 
> namespace X;
> 
> ...
> 
> namespace Y;
> 
> ...
> 
> 
> The problem is, no one thought of scoping "use" statements, so now
> those merged files share their "use" imports, thus breaking all the
> code where collisions occur.
> 
> Also we have the problems with name resolution of internal vs user
> classes and autoloaders, discussed here.

I just posted a patch that solves this problem, and a few minutes ago
forwarded two messages that further clarify how the patch works and why
it is a good solution to the problem.

> And we also have the non-intuitive differentiation between resolving
> functions/classes/constant which will most likely lead people to
> believe functions/constants aren't supported in any way in namespaces
> (if they try, and it doesn't work, they won't try second time).

The other 2 patches I have posted solve these issues decisively.

Since these would change namespace edge cases and introduce a new way to
import, I think an alpha3 is warranted.

The name resolution changes should not affect any existing working code
that utilizes namespaces, but should make it possible to do autoload
without having to "use" every single namespace class.

The patches do need review, and I am certain the patch introducing
function::blah::here() could be better written, and needs a Sara/Dmitry
type to take a quick look and say what could be done to improve it.

However, I don't think these facts warrant removal of the key feature of
namespaces, especially since they are relatively easy to solve - these
patches did not take many hours to whip up, and do not change very much.

Thanks,
Greg