Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40613
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 76.96.30.24 cause and error)
To: internals@lists.php.net
Date: Mon, 22 Sep 2008 22:39:07 -0500
User-Agent: KMail/1.9.9
References: <48D7F5EF.3090202@zend.com>
In-Reply-To: <48D7F5EF.3090202@zend.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <200809222239.07319.larry@garfieldtech.com>
Subject: Re: [PHP-DEV] namespace issues
From: larry@garfieldtech.com (Larry Garfield)

On Monday 22 September 2008 2:45:51 pm 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.

To clarify, with syntax B you can do multiple namespaces in one file?  I have 
no objection then.

> 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.

I am OK with this.

> 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?

"Most of the functionality could be easily achieved using static class 
methods".

As someone who uses both functions and classes with equal comfort, I have to 
say "GAH, NO NO NO!" to that statement.  Classes as pseudo-namespaces are 
fundamentally wrong.  Conceptually they're entirely different things.  I have 
to shut people down every time they try to suggest that in Drupal.  

It's not just a conceptual issue, either.  For a very practical example, 
consider that a namespaces can be split across any number of files.  A class 
must be all in one file.  That means if you want to group functions together, 
they MUST all be in one single monolithic file.  That makes them, sorry, 
useless for anything even remotely interesting.

No, namespaces for functions can most certainly *not* be emulated with either 
variable functions or static methods.  Dropping namespace support for 
functions makes namespaces mostly useless for anyone who is not 100% OOP.  
There's no reason to make functions second-class citizens (no pun intended).

-- 
Larry Garfield
larry@garfieldtech.com