Proposing a new extension : Autoload
| From: | Francois Laupretre | Date: | Sat, 08 Dec 2007 03:08:20 +0000 |
| Subject: | Proposing a new extension : Autoload | ||
| Groups: | php.pecl.dev | ||
| Request: | Send a blank email to pecl-dev+get-4958@lists.php.net to get a copy of this message | ||
Hi,
the extension I am proposing is an autoloader. This autoloader is currently
implemented in PHP and is integrated in the PHK runtime. But, as it is
independent of the PHK project and supports plain files as well as PHK
packages, I would like to implement it as a separate extension. The
objective here is to convert the PHP runtime code to a C extension, in order
to make it faster and to keep the autoload maps in persistent memory. For
those interested in the current PHP implementation, the code is available in
the 'download' section of the phk.tekwire.net site, download the
'PHK_Creator building kit' and the files are Autoload.php and
Autoload_Creator.php. Only Autoload.php (the runtime) will be ported as an
extension, as the code to create the symbol maps does not have to be
accelerated.
Every autoloaders existing today are based on a basic mapping mechanism
between the class names and a file hierarchy. The autoloader I am proposing
does not work this way: it uses some map files (lookup tables) to resolve
symbols. The map files are automatically created by a program which scans
the PHP scripts and extracts their symbols. At runtime, the main program
just needs to register the map file(s) in the autoloader runtime class
through calls to Autoload::load(). Then, classes are autoloaded when they
are referenced.
There are a lot of interesting things to underline on the benefits of this
approach, compared to the typical filename-based one. Here are the most
promising, imho :
- today, the main drawback of autoloaders is a huge impact in
performance because : 1. they are implemented in PHP, and 2. even if they
were ported to C, their logic generally involves at least one stat() call to
check for the file's existence. With pre-built map files, the runtime logic
is much simpler as most of the time-consuming tasks are done when the map is
created.
- as it supports any number of symbols per script file, it will allow to
extend the current autoload mechanism to functions and constants. Actually,
the map files it builds today already contain functions and constants
extracted from the PHP scripts. But, as long as the core does not provide a
callback mechanism for unresolved functions/constants, they can be resolved
only by explicitely calling Autoload::get_{constant|function}. Implementing
such a callback mechanism the same way it already exists for classes is
quite easy. But it was useless as long as the existing autoloaders did not
support more than one symbol per file.
- Apart from autoloading PHP script files, this autoloader also allows
to autoload extensions. As dl() is deprecated in future versions of PHP, it
will be interesting mainly for CLI mode. But, even if it cannot dl() the
extension at runtime in web mode, it will at least allow to output an error
message saying which extension contains the unresolved symbol and the syntax
of the line to add to php.ini.
OK, that's all. Thanks for your attention and let me know what you think
about it.
Regards
François