Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40670
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 208.83.222.18 cause and error)
Message-ID: <48DAC639.2000406@chiaraquartet.net>
Date: Wed, 24 Sep 2008 17:59:05 -0500
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070807)
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: namespace issues
From: greg@chiaraquartet.net (Greg Beaver)

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.

I'm happy with

#1 although I prefer 1 syntax to rule them all, I can live with this
#2
#3 if it also includes removing namespace constants

For future post-5.3, functions could be added back in.  The ambiguity
issue could easily be fixed by having a different scoping resolution
operator for namespaced classes vs. namespaced functions/consts.  For
instance:

<?php
blah::thing::mymethod(); // namespaced class blah::thing, method call to
mymethod
echo blah::thing::constant; // namespaced class blah::thing, class
constant constant
blah::thing:>func(); // namespaced function blah::thing:>func
echo blah::thing:>constant; // namespaced constant blah::thing:>constant
blah::thing:>$var = 1; // namespaced variable blah::thing:>$var (pure
fantasy, but illustrates the point)
blah::thing::$var = 1; // namespaced class blah::thing, class variable $var
?>

Before anyone gets all hyper, my point is *not* to introduce :>, but to
explain that it is in fact technically feasible to extend the definition
of namespaces later to add support for non-class elements and it would
work just fine.

It is, however, not going to be possible to do this post-5.3 without the
change above.

Note that we have a different operator for dereferencing static class
members (::) versus object members (->) for the reason that the thing
being dereferenced is different.  Namespaces are in fact different from
classes, so the problem with the current implementation is that the same
operator (::) used for both means we cannot allow any ambiguity between
namespace contents and class contents.

As long as classes cannot contain other classes:

<?php
class one {
   class dearGodNO {}
}
?>

then :: can be used for both namespace operator and static class
operator if functions/constants are removed from namespaces.

Greg