Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:25608
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain ratp.fr from 62.160.169.9 cause and error)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 11 Sep 2006 15:41:11 +0200
Message-ID: <C2F85D46E420FD4DB2065FE6901C6D0B410E41@EXCHANGE04.info.ratp>
Thread-Topic: RE: Multi-paradigm design (was: Re: [PHP-DEV] Re: __autoloading and ...
Thread-Index: AcbVp/GE+vgP1xUDTKumpG+An/oOXw==
To: <tslettebo@broadpark.no>,
	<internals@lists.php.net>
Subject: RE: Multi-paradigm design (was: Re: [PHP-DEV] Re: __autoloading and ...
From: francois.laupretre@ratp.fr (=?iso-8859-1?Q?LAUPRETRE_Fran=E7ois_=28P=29?=)

I agree. I don't understand why several people in the PHP team seem to =
consider that=20
the future of PHP and any improvement we can propose must be exclusively =
object oriented. I=20
really think that one of the biggest advantage of PHP against its =
competitors is its short=20
learning curve, especially because you don't have to learn to think 'the =
object way' before=20
writing your first script. And I am sure that more than half of the =
potential PHP users will=20
never use any object class in their programs.

Here are some of my arguments for the extension of the autoloading =
mechanism to functions AND=20
constants :

1. splitting a program and organizing it in several files would become =
easier, as these files=20
would be included when needed. This would be especially important for an =
interpreted language=20
which does not allow to detect unresolved symbols at compile time. So, =
by security, programmers=20
tend to include everything at the top of every source file and, as they =
don't want to manage=20
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=20
generally require that the upper level program include only one or two =
library file. As there's=20
no autoloading mechanisms where they could just register the rest of =
their source files, they=20
have to define every functions and constants at this time. Which means =
that including the=20
needed source files just in time would avoid the loading of a mass of =
unneeded code and could=20
greatly improve performance.

3. Of course, if the autoloading mechanism was extended, it should be =
complemented with a=20
default autoload handler, because I think that having people put one =
class per file and naming=20
the file after the class is a very basic and poor way of providing an =
autoloading feature. This=20
handler should be separated in two parts. One part would be called =
offline, scan the source=20
files, and would create a symbol map. At runtime, these maps would be =
used to resolve undefined=20
symbols.

4. I don't see why there would be a performance impact if the =
autoloading mechanism was=20
extended to functions and constants. It is just a hook in the error =
handler and does not slow=20
down the code for defined symbols.

5. An autoloading mechanism would also allow to autoload the extensions. =
The register tool I=20
talked about would register every constants, functions, classes, and =
interfaces defined by each=20
extension present on the host, and would store this information in a map =
file in the extension=20
dir. At run time, this file would be used to load the needed extensions =
JIT. Even the=20
documentation says that the dl() function is deprecated and that they be =
loaded through=20
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=20
extensions without having to modify the php.ini file. It would make it =
easier to distribute a=20
software requiring some specific extension.
    - it is important for CLI programs. Each of these programs has its =
own needs for extensions=20
and it can be a big loss of performance to load every extensions when =
every program is=20
launched. Maybe CLI programs are not important for you but it is still a =
supported feature and=20
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=20
offline tool to extract symbols (class, functions, constants, =
interfaces) from source files and=20
extensions and store them in map files, and a runtime handler to resolve =
these symbols. If you=20
are interested, it is distributed in the PHK packaging tool but can be =
used alone=20
(http://www.tekwire.net/redir.php?key=3Dphk, currently writing the doc).

Regards

Francois

Terje Sletteb=F8 wrote:
> Hi Marcus.
>=20
> 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.
>=20
> > The speed reasoning put aside we also found that procedural =
techniques
> > should not mix too much with the object oriented features.
>=20
> Could I ask why not?
>=20
> 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=3D167119), and aims =
at
> avoiding the myopic view people tend to get when only one "paradigm" =
is
> available to them (or familiar to them).
>=20
> 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.
>=20
> 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).
>=20
> However, I guess this discussion may not belong on internals... =
However, to
> use this concrete example, could you tell me why e.g.:
>=20
> $value=3DSomething::something(<something else>); // A related issue: =
Is this
> even OO? We're not operating on an object...
>=20
> would be better than:
>=20
> $value=3Dsomething(<something else>);
> ...