Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Re: Re: __autoloading and functions »

Re: Re: __autoloading and functions

php.internals

LAUPRETRE François (P)

19 years ago
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:

LAUPRETRE François (P)

19 years ago
Sorry, the URL to the Autoload manager is http://www.tekwire.net/joomla/component/option,com_docman/task,cat_view/gid,32/Itemid,47/ -----Original Message----- From: LAUPRETRE François (P) Sent: Tuesday, September 12, 2006 1:01 PM To: 'tslettebo@broadpark.no'; 'internals@lists.php.net' 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:

Terje Slettebø

19 years ago
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)" <francois.laupretre@ratp.fr> To: <tslettebo@broadpark.no>; <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

LAUPRETRE François (P)

19 years ago
Terje Slettebø wrote :
> 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).
I don't know if it is a great idea because you are the only one to be interested. Please feel free to download and use it (http://www.tekwire.net/joomla/component/option,com_docman/task,cat_view/gid,32/Itemid,47/). I would be glad to know that I am not the only one to use it in the world :-). I try to find time to write a small documentation but it is quite easy to use as there are only 3 files (Autoload.php is the runtime include, loading a map file uses Autoload::load(), Autoload_Builder.php is the CLI map builder and it has a '-h' flag to display its syntax). Until I write the doc, you will have to use it the PEAR way :-) (WYGIWYG, what you get is what you get). May I say that, on this subject and others, I am quite disappointed by the attitude of people on this mailing list. I tried to get some reactions about two projects I had been working on during several months (the Autoload handler and the PHK manager) and the few ones I got were mostly of the let-us-alone-and-keep-your-f..-ideas-for-you sort... It looks like you are the only one to understand that the process of getting the classes through corresponding filenames is quite primitive and can be improved. Even in the Zend framework, they implemented this stone-aged handler. Maybe it is normal because the list is regularly polluted by newbies who think they have solutions for everything when they have been working with PHP for 10 mins. That's why I have proposed to start a more formal RFC-like process where people who have really worked on a subject could propose changes and enhancements. This would eliminate the buzz of newbies and it would also provide a place to keep an history of proposals and decisions. It would also allow to implement a clean place for polls, instead of the poor process we saw during the last days about the filter extension. But, for this proposal like others, I didn't have any reply... Actually, I really think that, on this list, when you do not belong to a group of about 10-15 gurus, everything you say is systematically rejected. It is sad for PHP because (I'll get flames for this) this attitude is generally considered as an early characteristic of organizations on the decline. I am sorry to say that but I certainly won't waste more time with this list. Regards Francois

Stut

19 years ago
LAUPRETRE François (P) wrote:
> May I say that, on this subject and others, I am quite disappointed by the attitude of people > on this mailing list. I tried to get some reactions about two projects I had been working on > during several months (the Autoload handler and the PHK manager) and the few ones I got were > mostly of the let-us-alone-and-keep-your-f..-ideas-for-you sort... It looks like you are the > only one to understand that the process of getting the classes through corresponding filenames > is quite primitive and can be improved. Even in the Zend framework, they implemented this > stone-aged handler. > > Maybe it is normal because the list is regularly polluted by newbies who think they have > solutions for everything when they have been working with PHP for 10 mins. > > That's why I have proposed to start a more formal RFC-like process where people who have really > worked on a subject could propose changes and enhancements. This would eliminate the buzz of > newbies and it would also provide a place to keep an history of proposals and decisions. It > would also allow to implement a clean place for polls, instead of the poor process we saw > during the last days about the filter extension. But, for this proposal like others, I didn't > have any reply... Actually, I really think that, on this list, when you do not belong to a > group of about 10-15 gurus, everything you say is systematically rejected. It is sad for PHP > because (I'll get flames for this) this attitude is generally considered as an early > characteristic of organizations on the decline.
As a 'newbie' who has been hanging out on this list (for the most part quietly) I feel I have to respond to this. This list is not 'polluted' by newbies - the regular posters to this list are the core PHP developers. Anyway, to your points. Let's start with your assertion that "the process of getting the classes through corresponding filenames is quite primitive and can be improved". The mechanism provided by PHP for autoloading classes is by no means restricted to mapping classnames to filenames, but that is the simplest and most common implementation of __autoload that you will come across. Ever since this functionality was introduced to PHP I have been using a system that maintains a PHP include file containing an array of classes and the files they are defined in. This requires no work from the developers to maintain since, if it fails to find a class that has been requested it'll kick off a refresh of that cached file. It only fails completely if that rescan still cannot find the requested class. To me this is the logical way to implement functionality within the PHP engine itself. It doesn't enforce a certain way of implementing your class to file mapping. Instead it provides the basic framework so you can implement any mechanism you choose. As for the opinions of non-gurus being "systematically rejected" there is an element of truth to that. However, in my experience the "gurus" generally provide a good explanation of why a particular idea or comment is being rejected and most of the time it is completely justified. You have to understand that the "todo" list for PHP is extremely lengthy which means the devs have a difficult task when it comes to choosing what idea to implement and how. The fact that most individuals needs generally don't convert into high priorities is simply down to the fact that there are limited resources and literally thousands of people wanting different things to be added/changed. This is where you can get involved. If you have a particular need, grab the PHP source, implement it yourself and submit a patch. I've done this a coupla times, one (pathetically simple patch) was accepted, the other which was my first attempt highlighted that I did not understand the inner workings enough to make such a change. Finally, you suggest that "this attitude is generally considered as an early characteristic of organizations on the decline". I have to admit that made me chuckle. I've been lurking on this list for several years and the "attitude" has not changed much in that time but PHP is still going strong. Considering what they have achieved using that attitude I would think twice before criticising it. Bit of a ramble, sorry about that. Hopefully this won't be taken as a flame, just a response from an outside observer. -Stut

Richard Lynch

19 years ago
On Mon, October 2, 2006 9:15 am, LAUPRETRE François (P) wrote:
> Terje Slettebø wrote : > I don't know if it is a great idea because you are the only one to be > interested. Please feel > free to download and use it
...
> May I say that, on this subject and others, I am quite disappointed by > the attitude of people
...
> Maybe it is normal because the list is regularly polluted by newbies > who think they have > solutions for everything when they have been working with PHP for 10 > mins.
This is ludicrous. Most of the readers on this list have been working with PHP for *years* The fact is, several of them pointed out specific shortcomings to the idea involving performance and incompatibility with cache systems, which ties back in to performance. Do feel free to submit an actual patch to PHP source with benchmarks to prove them wrong...
-- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So?