Re: Re: __autoloading and functions
| From: | P) | Date: | Tue, 12 Sep 2006 11:01:12 +0000 |
| Subject: | Re: Re: __autoloading and functions | ||
| Groups: | php.internals | ||
| Request: | Send a blank email to internals+get-25632@lists.php.net to get a copy of this message | ||
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