RE: [PECL-DEV] Proposing a new extension : Autoload

Hi Alexey, and thanks for your interest once again ;). Actually, I just use this name as a package name, as the runtime API consists of static methods of this class. So, it can be anything, and changing it wouldn't even break PHK's BC. If someone has a better idea, I am open to any suggestion. Actually, as the pecl world is already full of acronyms, I thought that it would not be too bad to give a name with a real meaning. This way, if, one day, the extension is transferred to the PHP core, the API will be Autoload::load(), and a few utility methods (is_loaded($path), loaded_maps(), unload($path),...). Maybe this name is too generic, I'll think about it. PS: I know that people (not so many) use hand-made arrays to autoload their classes. I was talking of published autoloaders like the one in the Zend Framework. What I wanted to underline is that the 'hand-made arrays' method cannot be extended to big projects like the frameworks, or to projects with a lot of contributors. And, unfortunately, these projects are the ones who really need some autoloading, as it is very hard for them to manage their dependencies explicitely. As an example, the Zend Framework 1.0.1 library defines 721 classes. In practice, these projects need an autoloader but they cannot manage their symbol list by hand. So, the only solution for them, today, is to use a filename-based scheme. That's why the real added value of the autoloader I am proposing is not in the runtime, which is quite basic, but in the code to automatically extract the classes/functions/constants from the PHP code. 2nd PS: one more word on a side effect of explicit includes in libraries. In practice, when you explicitely include your dependencies, you have to embed your class definition in a 'if (class_exists(...' block because the file can be included several times. When you use an opcode cache, this code cannot be cached as efficiently as if the class definition appeared in the outer scope, and execution is slower. With an autoloader, you are sure that your source code won't be included twice. So, you can remove the 'if(class_exists' clause, making your code faster with a cache. The usual workaround is to use 'require_once' which is also not very fast. Regards François > -----Message d'origine----- > De : Alexey Zakhlestin [mailto:indeyets@gmail.com] > Envoyé : samedi 8 décembre 2007 10:46 > À : flconseil@yahoo.fr > Cc : PECL Dev > Objet : Re: [PECL-DEV] 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/ >