Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40619
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.163 as permitted sender)
Message-ID: <48D89F12.5050007@zend.com>
Date: Tue, 23 Sep 2008 11:47:30 +0400
User-Agent: Thunderbird 2.0.0.16 (X11/20080723)
MIME-Version: 1.0
To: Stanislav Malyshev <stas@zend.com>
CC: 'PHP Internals' <internals@lists.php.net>
References: <48D7F5EF.3090202@zend.com>
In-Reply-To: <48D7F5EF.3090202@zend.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] namespace issues
From: dmitry@zend.com (Dmitry Stogov)

Stanislav Malyshev wrote:
> Hi!
> 
> On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk about
> what we'd like to do with namespaces, and we arrived at the following
> conclusions, which we propose to implement in 5.3:
> 
> 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.
> 
> 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.
> 
> 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.
> 
> Comments?

Great, lets castrate the language to make it consistent. :(

1. I am fine with (1), except for unspecified scope of "use" statement
inside namespace with bracket. I assume it should affect only current
declaration and not the following namespace declarations (even with the
same name).

2. This is acceptable only if we accept (3) otherwise we will need to
write ::strlen() and so on.

3. In case we remove functions we also need to remove constants as they
have exactly the same ambiguity problems. It's unclear for me what the
following code will define after all (global function or just emit a
parse error?)

<?php
namespace foo {
  function bar() {
  }
}
?>

Thanks. Dmitry.