Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40684
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 88.198.8.16 cause and error)
Cc: Stanislav Malyshev <stas@zend.com>,
 'PHP Internals' <internals@lists.php.net>
Message-ID: <C408830A-4287-4B60-AF21-1EE08CBC0F90@pooteeweet.org>
To: Dmitry Stogov <dmitry@zend.com>
In-Reply-To: <48D89F12.5050007@zend.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Thu, 25 Sep 2008 16:09:16 +0200
References: <48D7F5EF.3090202@zend.com> <48D89F12.5050007@zend.com>
Subject: Re: [PHP-DEV] namespace issues
From: mls@pooteeweet.org (Lukas Kahwe Smith)


On 23.09.2008, at 09:47, Dmitry Stogov wrote:

> 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() {
>  }
> }
> ?>


Right, Stas, did you also discuss removal of constants? Seems logical  
as the really the same arguments apply.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org