Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:17405
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Tue, 26 Jul 2005 10:10:45 +0200
Reply-To: Marcus Boerger <mail@marcus-boerger.de>
Message-ID: <1374121835.20050726101045@marcus-boerger.de>
To: Jessie Hernandez <jrhernandez05@gmail.com>
Cc: internals@lists.php.net
In-Reply-To: <79.5B.58254.6DCA5E24@pb1.pair.com>
References: <52.31.61486.E8DCDD24@pb1.pair.com>
	<1122328113.647.16.camel@boost.home.ahk>
	<538910800.20050725235918@marcus-boerger.de> <79.5B.58254.6DCA5E24@pb1.pair.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PATCH] Namespace Patch, Alpha 3
From: mail@marcus-boerger.de (Marcus Boerger)

Hello Jessie,

Tuesday, July 26, 2005, 5:24:02 AM, you wrote:

> Marcus Boerger wrote:

>> 
>> You already have the ability to overload __autoload or provide several
>> userspace __autoload functions that would be called one after another
>> until the first succeeds. What else do you want? Besides the fact that
>> i am still convinced that we should find a way to pass the full namespaced
>> name to __autoload instead of just the classname. If you ask me not doing
>> so is simply an error.
>> 

> I still think that the namespace importing logic/file-naming convention is
> the cleanest, but if __autoload is to be used, then I currently see three
> approaches to this:

> 1) Search in each directory in the class_path (or include_path) for
> "namespace-name/class-name.php". When the first file is found, then the
> full class name will be generated from that and passed on to __autoload,
> e.g. if you import the my_ns namespace and use class1, then
> my_ns/class1.php will be searched in the path and then __autoload will be
> called with "my_ns:class1".

> Requirements
> ------------
> - Namespace/class naming convention

> Pros
> ----
> - Full class name is passed to __autoload

> Cons
> ----
> - Performance loss (when the directories are searched, the path to the class
> file is already known before __autoload is called, so generating the full
> class name from the path, calling __autoload, only to then str_replace
> colons with slashes and including that seems unnecessary).
> - When a class name exists in more than one imported namespace, the first
> one found will be passed to __autoload (no way to disambiguate).

> 2) Like (1), but search all the directories and pass an extra argument (or
> pass an array or object as the first argument) to __autoload indicating the
> directories where the class name was found. The first argument would be the
> class name, the second argument (or an additional key in the array) would
> contain the paths (or namespace names, whichever). The user would be
> responsible for disambiguation in case a class exists in multiple imported
> namespaces.

> Requirements
> ------------ 
> - Namespace/class naming convention

> Pros
> ----
> - No ambiguity
> - The include behavior is handled completely by the user

> Cons
> ----
> - In the majority of cases, a class name will not appear in more than one
> namespace, so there will be a performance loss by having to search all the
> directories in the class/include_path, even though there was a match on the
> first directory.

> 3) Simply pass an extra argument (or pass an array or object as the first
> argument) to __autoload containing the names of the imported namespaces of
> the calling file. __autoload can then use this array against the class name
> and perform its own lookup.

> Requirements
> ------------
> - None

> Pros
> ----
> - A namespace/class naming convention is not forced
> - The include behavior/lookup is handled completely by the user
> - No performance loss (all that's passed to __autoload is the class name and
> an array of imported namespaces, and this is done immediately).

> Cons
> ----
> - IMHO, I think most users would maintain a naming convention similar to
> Java's, so the user would have to add code for something which the language
> should handle for them. This can be minimized, though, if a function is
> added to handle this common behavior. The function can be called by the
> user in __autoload and will look something like the following (of course,
> the code would be in C):

> <?php
> function namespace_include($className, $importNamespaces)
> {
>     $paths = explode( PATH_SEPARATOR, get_include_path() );
 
>     foreach( $paths as $path )
>     {
>         foreach( $importNamespaces as $ns )
>         {
>             $fullPath = $path . DIRECTORY_SEPARATOR . str_replace( ':',
> DIRECTORY_SEPARATOR, $ns ) . DIRECTORY_SEPARATOR . $className . '.php';
 
>             if( file_exists( $fullPath ) )
>             {
>                 require_once( $fullPath );
>                 return true;
>             }
>         }
>     }

>     return false;
> }
?>>


> I still think the namespace import behavior should be separate from the
> __autoload function. Of course, this is just me. What does everyone else
> think? I'd like to gather opinions on which is preferred. I will also like
> to know if a separate class_path is preferred (as I have in my last patch)
> or if just leaving include_path is what most prefer.

None of the above makes any sense. Look __autoload() is just bein called at
any place where a class is missing. So looking for the file first and then
loading __autoload(I) makes no sense whatsoever. IMO what we need here is a
default implementation for import behavior accomplished by __autoload(). So
for example "import ns:cls;" leads to "__autoload('ns:cls')". Here the SPL
default implementation would relpace all ':' with the directory divider '/'
or '\', append '.inc' or '.php' or '.inc.php' and append the result to all
directories in the include_path to look for the file. If were are to support
import with '*' the the autoload implementation would need to take care of
this and load all matching files. A user land implementation can easily
achieve that by using SPLs (Recursive)DirectoryIterator and FilterIterator.

Best regards,
 Marcus