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