Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40610
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain iamjochem.com from 194.109.193.121 cause and error)
Message-ID: <48D80EAD.4070601@iamjochem.com>
Date: Mon, 22 Sep 2008 23:31:25 +0200
User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707)
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; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] namespace issues
From: jochem@iamjochem.com (Jochem Maas)

Stanislav Malyshev schreef:
> 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.

super. mixing of syntax is a parse error, right?
fancy taking a sportsmans bet as to which will be used more in the wild?
my 'money' is on syntax B. ;-)

> 
> 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.

again super ... by the sounds of it (I have a sneaking suspicion that
some edge-case resolution pains may still crop up but that's what edge-case are
all about ... if you could spot them all they'd call you <DEITY> :-))

> 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.

given that the general distaste for Greg 'namespace member' proposal this
seems like the only other suitable option to resolve current ambiguity issues.

using abstract classes to 'namespace' functions has been a quite wide spread
practice for a while now anyway. it is likely that function() proponents will
balk at the idea of not being able to namespace them but that's less painful
to explain than having to deal with the current situation, imho.

which leaves the question of namespaced constants ... they suffer the same
problems as functions and can also be achieved via classes, I request that
you therefore remove them as well as functions.

rgds,
Jochem

PS - pity Greg's patch was so disliked, I rather liked it myself and would
have allowed constants and functions inside namespaces ... guess that's life :-)

> Comments?