Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40709
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 192.18.6.21 as permitted sender)
Date: Fri, 26 Sep 2008 21:24:44 +0200
In-reply-to: <48D7F5EF.3090202@zend.com>
Sender: Johannes.Schlueter@Sun.COM
To: Stanislav Malyshev <stas@zend.com>
Cc: "'PHP Internals'" <internals@lists.php.net>
Message-ID: <1222457084.16613.83.camel@goldfinger.johannes.nop>
MIME-version: 1.0
Content-type: text/plain
Content-transfer-encoding: 7BIT
References: <48D7F5EF.3090202@zend.com>
Subject: Re: [PHP-DEV] namespace issues
From: johannes@php.net (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

Hi,

On Mon, 2008-09-22 at 12:45 -0700, Stanislav Malyshev wrote:
> 1. Allow braces for namespaces. So, the syntax for namespaces will be:
> a) namespace foo;
> should be first (non-comment) statement in the file, namespace extends 
> to the end of the file or next namespace declaration.
> b) namespace foo {}
> can appear anywhere on the top scope (can not be nested).
> Mixing both syntaxes in one file is not possible. The semantics of both 
> syntaxes will be identical.

I'm fine with that, personally I'd like having only the {}-Syntax but as
many people want both, well, ...
For future times (6.0) we might think about adding nesting support - if
we get it working good with the engine, but no show-stopper, we're
"delayed" enough...

> 2. Simplify resolution order for classes in the namespace: unqualified 
> names are resolved this way:
> a) check "use" list if the name was defined at "use", follow that resolution
> b) if not, the name resolves to namespace::name
> Consequence of this will be that for using internal class inside 
> namespace one would need to refer to it either as ::Foo or do use ::Foo 
> prior to its usage.

That will hurt a bit when working with DOM for example, but still +1.

> 3. Functions will not be allowed inside namespaces. We arrived to 
> conclusion that they are much more trouble than they're worth, and 
> summarily we would be better off without them. Most of the functionality 
> could be easily achieved using static class methods, and the rest may be 
> emulated with variable function names, etc.

That's fine, I'm not sure about constants, neither one way nor the
other, but in general I see some support for dropping them.

johannes