I agree. I don't understand why several people in the PHP team seem to consider that
the future of PHP and any improvement we can propose must be exclusively object oriented. I
really think that one of the biggest advantage of PHP against its competitors is its short
learning curve, especially because you don't have to learn to think 'the object way' before
writing your first script. And I am sure that more than half of the potential PHP users will
never use any object class in their programs.
Here are some of my arguments for the extension of the autoloading mechanism to functions AND
constants :
1. splitting a program and organizing it in several files would become easier, as these files
would be included when needed. This would be especially important for an interpreted language
which does not allow to detect unresolved symbols at compile time. So, by security, programmers
tend to include everything at the top of every source file and, as they don't want to manage
dependencies, they also tend to write their programs in few large source files.
2. When writing a library, in order to keep the API as simple as possible, programmers
generally require that the upper level program include only one or two library file. As there's
no autoloading mechanisms where they could just register the rest of their source files, they
have to define every functions and constants at this time. Which means that including the
needed source files just in time would avoid the loading of a mass of unneeded code and could
greatly improve performance.
3. Of course, if the autoloading mechanism was extended, it should be complemented with a
default autoload handler, because I think that having people put one class per file and naming
the file after the class is a very basic and poor way of providing an autoloading feature. This
handler should be separated in two parts. One part would be called offline, scan the source
files, and would create a symbol map. At runtime, these maps would be used to resolve undefined
symbols.
4. I don't see why there would be a performance impact if the autoloading mechanism was
extended to functions and constants. It is just a hook in the error handler and does not slow
down the code for defined symbols.
5. An autoloading mechanism would also allow to autoload the extensions. The register tool I
talked about would register every constants, functions, classes, and interfaces defined by each
extension present on the host, and would store this information in a map file in the extension
dir. At run time, this file would be used to load the needed extensions JIT. Even the
documentation says that the dl() function is deprecated and that they be loaded through
php.ini, I still think that it is an important feature to provide, mainly for two reasons :
- it allows people to install PHP and start using it with the full power of every
extensions without having to modify the php.ini file. It would make it easier to distribute a
software requiring some specific extension.
- it is important for CLI programs. Each of these programs has its own needs for extensions
and it can be a big loss of performance to load every extensions when every program is
launched. Maybe CLI programs are not important for you but it is still a supported feature and
should be considered (PHP-Gtk not dead yet :-).
6. This is not a definitive argument :-), but I have written such an autoload handler, with an
offline tool to extract symbols (class, functions, constants, interfaces) from source files and
extensions and store them in map files, and a runtime handler to resolve these symbols. If you
are interested, it is distributed in the PHK packaging tool but can be used alone
(http://www.tekwire.net/redir.php?key=phk, currently writing the doc).
Regards
Francois
Terje Slettebø wrote:
