Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51166
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 76.96.27.212 cause and error)
To: internals@lists.php.net
Date: Fri, 31 Dec 2010 13:04:06 -0600
User-Agent: KMail/1.13.5 (Linux/2.6.34.7-0.5-desktop; KDE/4.4.4; x86_64; ; )
References: <AANLkTi=26zb0xyOV5JLoZsUdxxVEdZAntorT+XczfkYn@mail.gmail.com>
In-Reply-To: <AANLkTi=26zb0xyOV5JLoZsUdxxVEdZAntorT+XczfkYn@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-ID: <201012311304.06795.larry@garfieldtech.com>
Subject: Re: [PHP-DEV] RFC - Namespace initializers
From: larry@garfieldtech.com (Larry Garfield)

On Friday, December 31, 2010 7:56:39 am Nicolas Grekas wrote:
> Dear all,
> 
> this RFC started by me having a problem on these subjects (not only me
> I think) :
> - namespaced functions and constants loading, or rather not-autoloading,
> - interfaces loading (this time, autoloading).

<snip>

> So, my first proposal for namespaced functions and constants is :
> 1. Remove namespaced functions and constants at all - promote
> namespaced public static methods and class consts instead.
> 
> This would fix static code analysis, and the discussion about how to
> autoload (I may say "how to package") namespaced functions and
> constants would vanish. About backward compatibility, who as written
> code relying on namespaced functions or constants? They are useless!

Dear god no!  Functions are already close to being second-class citizens in 
PHP at this point.  The project I work on (Drupal) is currently debating how 
to leverage function namespaces for our next version and there are several 
ways that we could do so effectively; mostly they come down to module == 
namespace, and then a "hook" (magic function callback) can be placed within a 
namespace.  That would actually make for clearer code than our current model.

Class == namespace is wrong.  Plain and simple.  It is a broken assumption 
based on broken understanding and the use of them that way is broken.  That 
approach is utterly useless if you want any sort of flexibility.

> My second proposal is :
> 2. At runtime, when a namespaced identifier is used (lets say
> \my\sub\ns\class_interface_constant_or_function), take the namespace
> part of the identifier and if any, autoload it as if it were a class,
> do not generate any error if the given class name is not found. (ie,
> trigger something like class_exists('my\sub\ns', true);).

I am not entirely sure I follow.  Are you suggesting that:

use Stuff\Things as Bar;
$foo = new Bar\Baz\Foo()

should trigger:

autoload('Stuff\Things\Baz\Foo');

AND

autoload('Stuff\Things\Baz')?

In the current approach I don't know how you'd properly resolve the "namespace 
portion" of the extended class/function/whatever name.  Honestly, combined 
with the previous proposal(s) for function autoloading (which I support in 
general)  it seems to me that we need to have separate but parallel pathways 
for autoloading different things; that could lead to better performance, too.  
If we can properly separate them I can see a use for "clustered" autoloading, 
certainly, and namespace is a not-unreasonable definition of cluster.

> Cons :
> - none
> - well, one : I don't speak C, so I don"t have any patch...

I sadly have the same problem. :-)

--Larry Garfield