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.
--
Jessie
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
