Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40213
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender)
Date: Tue, 2 Sep 2008 14:04:19 +0200
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <1749932734.20080902140419@marcus-boerger.de>
To: Stanislav Malyshev <stas@zend.com>
CC: Lukas Kahwe Smith <mls@pooteeweet.org>, 
	PHP Internals List <internals@lists.php.net>
In-Reply-To: <48BCF217.3010401@zend.com>
References: <0E6B0C09-99C4-4843-A8E6-0B015EB98B4E@pooteeweet.org> <48BCF217.3010401@zend.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] namespace RFC
From: helly@php.net (Marcus Boerger)

Hello Stanislav,

Tuesday, September 2, 2008, 9:58:15 AM, you wrote:

> Hi!

>> So I ask you all to review the RFC and provide feedback. If you feel 

> Here's my feedback on the RFC.

> 1. The RFC seems to assume or imply that PHP programmers have extensive 
> C++ experience. IMHO it is not true for the majority of PHP programmers.

> 2. Phar has nothing to do with file concatenation, as if was noted, and 
> concatenation's use is entirely unrelated to phar (and, before you 
> mention it, to bytecode caches - they can be used together, but one does 
> not preclude the other).

Yet, both are a means of deployment. Which is why I mentioned that. If you
do concatenation purely for speed then Phar is not the way to go.

> 3. Namespaces are *NOT* code flow control structure. Giving it a syntax 
> of a control structure is misleading, requiring "endnamespace" at the 
> end of each file makes no sense and just adds busywork for people. It 
> also is awfully ugly - braces at least have some decent looks...
> Namespace also is not like a label in any way - it does not specify 
> point in code and you can not jump to it using either conditional (like 
> switch/case:) or unconditional (like goto) branch.

It controls naming and name lookup. End of the story.

Current version looks like a misspelled version of labels and alternative
syntax which simply adds confusion.

> 4. I did not understand first paragraph of part named "Statements 
> outside namespaces" - what is has to do with caches? Could somebody 
> explain it to me (private mail/IRC/IM OK).

I don't know it either, it is something that came up several times so I put
it into the RFC.

> 5. I am not sure which exactly code RFC proposes to allow outside 
> namespaces, in any case I don't see why it is necessary to allow any 
> code to be put outside namespaces in namespaced files. For include, it 
> doesn't matter anyway, since included file has its own namespace, for 
> the rest I'm just unclear what else is proposed, please explain.

I am sorry but I absolutely fail to see how the following is in any way
whatsoever unclear:

====
Proposal and Patch

We propose to add namespaces as block structures and drop 'namespace foo;' in favor of 'namespace foo: ; endnamespace;', as in this patch. The tests are provided in a second patch.

In a second step nesting namespaces should be supported. This can easily be done by simply removing the corresponding error messages.
====

> 6. Comment about "we kind of allow nested namespaces" because we allow 
> namespace in included file is wrong. These namespaces live absolutely 
> separately and are not nested in any meaningful way. All files in PHP 
> except for the head script are obtained by means of include(), so it is 
> only natural that namespace is allowed inside include - it would be 
> useless otherwise. Included file, however, creates it own namespacing 
> scope, and just as we do not say we allow nested classes because file 
> defining class can be included from inside any other class, same holds 
> for namespaces.

> 7. Nested namespaces. I see that RFC authors chose to completely ignore 
> all my comments about namespace nesting, so I repeat them again for the 
> record.
> Nesting namespaces implies hierarchy, hierarchy implies hierarchical 
> resolution, so if you inside namespace A::B::C::D::E::F, then name G is 
> expected to resolve when it means either A::G, A::B::G, A::B::C::G, etc. 
> Combined with autoloading, this makes resolution process prohibitively 
> expensive, and not resolvable in runtime by any means - since even if 
> you wrote A::B::C::D::E::F::G it could still mean 
> A::B::C::A::B::C::D::E::F::G - since you have not one-level resolution 
> but hierarchical resolution, even qualified name could be partial name.
> Making nesting without hierarchy doesn't make any sense - why nest then, 
> what purpose would it serve?

namespace A::B::C::D::E::F;
$obj = new G;

Now what?

> [...bla...]

> Regards,
> -- 
> Stanislav Malyshev, Zend Software Architect
> stas@zend.com   http://www.zend.com/
> (408)253-8829   MSN: stas@zend.com




Best regards,
 Marcus