Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41759
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fmethod.com from 69.16.228.148 cause and error)
Message-ID: <8958389FB3694464893373C7263C2EBC@pc>
To: <internals@lists.php.net>
References: <4EA88C3A8A2747989925A5D21448FCE7@pc> <491333F2.5070105@zend.com> <91597FF883CD4BA3861A5C72134BCA56@pc> <4913C1CF.3070305@gmail.com> <1226042871.4679.23.camel@goldfinger.johannes.nop> <4913F642.6090703@invisihosting.com>
Date: Fri, 7 Nov 2008 18:24:38 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Call it: allow reserved words in a class or not?
From: sv_forums@fmethod.com ("Stan Vassilev | FM")

> What about adding a function that behaves like __autoload, but with
> respect to namespace wildcards?  Something like:

Hi,

Ok so first:

1) We can't implement wildcards since a wildcard needs to be expanded to a 
set of concrete classes at runtime for it to make sense, and we don't know 
what those classes are (due to autoloads and "conditional" require/include 
constructs).

2) There can't be a method to resolve wildcards, since namespaces currently 
work 90% at the parse level, before any PHP code has executed. This is 
required for good performance and simplicity.

3) I have emailed Greg a simple idea for solving this with a INI-like "meta" 
namespace file, a simple file we can put in our include path, which 
describes the resources of a namespace and optionally their location.

For example let's say you have namespace My\Name\Space, and inside you have 
classes "Foo", "Bar", functions "baz" and constants ONE, TWO. In one of your 
include paths, you'll create a file called "My.Name.Space.nsmeta" and put 
the following inside:

class Foo = "path\to\Foo.class.php"
class Bar = "path\to\Bar.class.php"
function baz = "path\to\baz.func.php"
const ONE = "\path\to\constants.php"
const TWO = "\path\to\constants.php"

This file you can generate from your framework, or even write by hand, as 
you see it's very simple to write/read, and tokenizes with the existing PHP 
tokenizer.

Since this file will be read at parse time, it has the ability to solve the 
following problems:

1) zero-performance-impact namespace wildcards (especially with an opcode 
cache like APC, XCache etc.)
2) faster resource loading (PHP can autoload resources from the location map 
above without you writing a slow __autoload runtime procedure)
3) you can load on demand now any namespace resources: class, functions, 
constant, not just classes.

Naturally this is not for 5.3 as we all want 5.3 stable and out as soon as 
possible. But it has the potential to simplify drastically some workflows, 
especially in large complex frameworks, so if it picks up, maybe 5.4, or 6 
or who knows.

Regards,
Stan Vassilev