# Multi-paradigm design (was: Re: Re: __autoloading and ... - Thread: https://externals.io/message/25608 - Original archive: https://news-web.php.net/php.internals/25608 - Started by francois.laupretre@ratp.fr on 2006-09-11T13:41:11+00:00 - Messages: 1 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #25608 — francois.laupretre@ratp.fr — 2006-09-11T13:41:11+00:00 URL: https://externals.io/message/25608#25608 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. > > > […] > > 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(); // A related issue: Is this > even OO? We're not operating on an object... > > would be better than: > > $value=something(); > ...