Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40471
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fmethod.com from 69.16.228.148 cause and error)
Message-ID: <EDD81B0D532744D4A80E7AFA2AA377FE@pc>
To: <internals@lists.php.net>
Date: Thu, 11 Sep 2008 18:32:13 +0300
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0024_01C9143C.B5CAF460"
Subject: Scoping of "use" statements and a strategy for 5.3/6.0 release of namespace
From: sv_forums@fmethod.com ("Stan Vassilev | FM")

------=_NextPart_000_0024_01C9143C.B5CAF460
Content-Type: text/plain;
	charset="windows-1251"
Content-Transfer-Encoding: quoted-printable


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.

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).

Which leads me to the following proposal:

For PHP 5.3 we introduce namespaces with a very limited "safe" set of =
barebones features, that we won't regret later for releasing and having =
to modify in a non-BC way. It'll let people start porting their code and =
be ready for the full featureset later on, which will be a proper =
superset of the 5.3 release:

1) We disable support for multiple namespaces per file as it is, as it =
can't be used without ability to scope "use" statements as well.

2) We remove the statement "use" (regarding namespaces, not regarding =
closures), until we get more feedback from the community on the exact =
preferred resolution algorithms, and more thought is put to this.

For PHP 5.4 or 6:

1) Introduce file-level "use" statements with same syntax as now, but =
modified resolution rules based on further discussion and feedback. And =
if someone is about to say "we had plenty of discussion", well it's =
apparent we didn't have enough given all the problems facing namespaces =
right now, or maybe not enough of the constructive type of discussion.

2) Introduce ability to scope "use" and "namespace" statements with =
curly brackets, so that multiple files can be safely merged without =
changing intent (all file-level namespace can be converted with curly =
brackets, and the existing curly bracket ones don't need to be =
converted), example:

namespace X {
    use Y as Z {
        ...
    }
}

namespace Y {
    use X as Z {
        ...
    }
}


Waiting for your feedback...

Regards,=20
Stan Vassilev 
------=_NextPart_000_0024_01C9143C.B5CAF460--