Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40697
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 76.96.62.48 cause and error)
To: internals@lists.php.net
Date: Thu, 25 Sep 2008 23:36:05 -0500
User-Agent: KMail/1.9.9
References: <48D7F5EF.3090202@zend.com> <200809222239.07319.larry@garfieldtech.com> <F8989E81-2BE8-4196-A86C-5A94D3A00497@pooteeweet.org>
In-Reply-To: <F8989E81-2BE8-4196-A86C-5A94D3A00497@pooteeweet.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <200809252336.05332.larry@garfieldtech.com>
Subject: Re: [PHP-DEV] namespace issues
From: larry@garfieldtech.com (Larry Garfield)

On Thursday 25 September 2008 9:08:27 am Lukas Kahwe Smith wrote:

> > 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).
>
> sure point taken on the monolithic files, when sticking different
> functions into classes just for the sake of them then becoming
> namespaceable. but how would allowing functions in namespaces solve
> this issue?
>
> regards,
> Lukas Kahwe Smith
> mls@pooteeweet.org

Functions in namespaces serve the same purpose as classes in namespaces, for 
whatever that purpose is this week. :-)  It allows for shorter function names 
for related functions (that cannot be part of the same class for practical 
architectural reasons, as mentioned, or for conceptual reasons) and for 
clustering of functionality in ways that classes are ill-suited for.

Another advantage is for differentiation.  One problem we have run into in 
Drupal is that if we have a function named "foo_bar_baz()", is that 
the "bar_baz()" function of the "foo" module/namespace or is it the "baz()" 
function of the "foo_bar" module/namespace?  (We are trying to implement some 
performance enhancement logic that depends on knowing the difference between 
those two case.)  Note that we cannot forbid such modules/namespaces as 
anyone can write a module named whatever they feel like.  

In theory we could use a double underscore, foo__bar_baz(), but that's just as 
silly as class Zend_Controller_Factory_View_Plugin_Thing.

Ideally we could do foo::bar_baz(), eliminate the ambiguity, and make it 
easier for module developers, too.  Just define your module as a namespace 
and then you always have a function bar_baz() inside it.  And we can continue 
to split modules across multiple files (absolutely critical for performance) 
and allow modules to define functions on behalf of another module (absolutely 
critical for functionality).

See the sample code I posted back on 9/9 in response to your request for 
implementations.

My point in the GP post is that "you can just use static methods" to emulate 
namespaces for functions is wrong, and cannot be used as an argument that 
functions do not need or should not get namespaces.

-- 
Larry Garfield
larry@garfieldtech.com