Hi François. I think this sounds like a great idea. :) We do something similar with our class loader, in that it scans a lib-directory and its subfolders, building a map of class name to filename (it doesn't open the files - it only builds the map based on file naming convention, allowing it to infer the class name from the file name, if a file contains a class) and storing it in the session. Yet, something that didn't have to be rebuild at session startup would be even better.
Of course, one could serialise this information, but then it becomes important that it updates it when there are relevant file changes (like your CLI program can do). Regards, Terje ----- Original Message ----- From: "LAUPRETRE François (P)" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <internals@lists.php.net> Sent: Tuesday, September 12, 2006 1:01 PM Subject: Re: Re: __autoloading and functions Yes, the trivial answer is to name each file after the symbol it contains, but it limits to one symbol per file (and I was talking about autoloading constants ! :-). Once again, if we don't propose a smarter autoload manager, extending the autoload feature to functions is not very interesting because, for most PHP programmers, it won't make their task easier (and it won't allow to autoload extensions, which would be a big step forward). I would be glad if people interested in this subject could have a look at an autoload manager I have written and which could, IMHO, solve most of these problems. It contains two parts : a CLI program to scan source files and extensions and store their symbols in map files, and a runtime resolver which will use these files. A map file can contain symbols for any number of source or extension files allowing, for instance, to put only one map file in the extensions directory to store the symbols of every extensions present on the host. As there is no hook at this time in the PHP engine to autoload functions and constants, their resolutions must be explicitely requested before using the symbol but, if the autoload feature was extended to these symbol types, the autoloader would be completely transparent to the client programs. Of course, it is written in PHP today but it would be quite easy to rewrite it in C and integrate it to the core. If it was integrated to the core and if we added a cache to keep symbol maps in memory, I am sure that the speed up due to JIT loading would balance the autoloading overhead. Please tell me what you think about it. Regards François Terje Slettebø wrote: > > > In either of the above cases, you specify where a function belongs, both > > > where it's defined, and where it's used (either through full > qualification, > > > or a shorter one, using "import"). I'm not arguing for a function to > > > "magically" become a part of a class/module/whatever, if you thought so > > > > > Then the question is how do you think this function would be used? > > That's a very good question... One "simple" answer would be to have one file > per function, and have it work like typical class autoloaders. However, that > could be too much overhead (on many levels), having a lot of small files, > that conceptually belong together. > > Maybe function autoloading isn't such an obvious feature, after all (which > was one reason for bringing it up - getting the pros and cons of it. By the > way, I've now also read in on the archive of this and the other issues > having been mentioned in this thread, such as namespaces). > > Regards, > > Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
