Re: Proposing a new extension : Autoload

sounds like it can be useful, but I don't like the name. It is too general p.s. not all autoloaders use direct filesystem mapping. I use hand-made arrays in my projects (because I know, exactly, what goes in and what doesn't). On 12/8/07, Francois Laupretre <flconseil@yahoo.fr> wrote: > 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 > -- Alexey Zakhlestin http://blog.milkfarmsoft.com/