Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33961
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 38.99.98.18 cause and error)
Message-ID: <475F8091.7080502@chiaraquartet.net>
Date: Wed, 12 Dec 2007 00:32:49 -0600
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Jessie Hernandez <jrhernandez05@gmail.com>
CC: internals@lists.php.net
References: <97.BF.38526.B657F574@pb1.pair.com>
In-Reply-To: <97.BF.38526.B657F574@pb1.pair.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: Idea for namespace lookup resolution
From: greg@chiaraquartet.net (Gregory Beaver)

Jessie Hernandez wrote:
> I just thought of something that might be a solution to the lookup rules
> that we currently have in the namespaces implementation. Whether it's
> good or not, I just wanted to throw it out there. Here goes:
> 
> Support a user-defined function named __get_namespace_classes, which
> will be similar to __autoload. The signature of the function would be
> the following:
> 
> 
> array __get_namespace_classes(string $namespaceName);
> 
> Returns an array of names of classes that are under the specified
> namespace, or FALSE if the classes under the namespace could not be
> determined.
> 
> 
> The above function would be used in the lookup rules as follows (using
> DateTime as an example):
> 
> 1) Does the class DateTime exist in the current namespace?
> 2) If not, and the function __get_namespace_classes exists, call
> __get_namespace_classes.
> 3) If the string DateTime is returned in the array from
> __get_namespace_classes, then autoload that class.
> 4) If the class is not in the resulting array, or if the result was
> FALSE, then look for an internal class DateTime.

This is of course a possibility, but it would be a tremendous
performance hit both in terms of memory and processing time.  The use
statements that specify dependencies are compile-time with minimal
memory consumption and no performance hit at all, not to mention they
only need be updated when using different classnames.

All of my experience in coding thus far says that the addition of a new
class to a file is exceedingly rare, and having to add that use line at
that point would not be any more difficult than it is to remember to use
a semi-colon or close matching "" or ().

I of course wouldn't stand in the way of this proposal if others think
it is the way to go, but there's no way I would use it or recommend it
as a coding practice for PEAR2.

Thanks,
Greg