Proposing a new extension : Autoload

From: 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

« previous php.pecl.dev (#4958) next »