Multi-paradigm design (was: Re: Re: __autoloading and ...

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:

Hi Marcus.

Thanks for the replies, both of you. I've solved this particular problem by
having all these little functions in a file that gets included for all files
that need it.

The speed reasoning put aside we also found that procedural techniques
should not mix too much with the object oriented features.

Could I ask why not?

I can give my own thoughts to the opposite: I (and much of the programming
community, it seems) have come to that it's a perfectly reasonable way to
program, where you use the best abstractions for the task (ironically, PHP
is better than Java in this respect, as Java doesn't support free
functions). This goes under the name of multi-paradigm design
(http://www.artima.com/weblogs/viewpost.jsp?thread=167119), and aims at
avoiding the myopic view people tend to get when only one "paradigm" is
available to them (or familiar to them).

In fact, combining "paradigms" is what gives MPD much of its power, as it
enables you to do things that no single "paradigm", by itself, can do.

Trying to shoehorn everything into one "paradigm" (whether it's procedural
programming, OO, functional programming, or whether) may lead to some very
contorted designs... To paraphrase a well-known phrase: If all you know is
OO, everything will look like an object (whether or not it makes any sense).

However, I guess this discussion may not belong on internals... However, to
use this concrete example, could you tell me why e.g.:

$value=Something::something(<something else>); // A related issue: Is this
even OO? We're not operating on an object...

would be better than:

$value=something(<something else>);
...