A Potted History of PHP
PHP began life in 1995 as little more than a series of perl scripts developed by the cheesily-begrinned Rasmus Lerdorf. Originally entitled 'Personal Home Page tools', they were predominantly used to track usage of his website and ease certain maintenance tasks. Interest in them grew and he reimplemented them directly in C, including such useful features as database connectivity and primitive dynamic content manipulation. This was subsequently released as PHP/FI ('Personal Home Page / Forms Interpreter').
In 1997, two students (Andi Gutmans and Zeev Suraski), rewrote much of what was then PHP/FI v2.0 to aid in the construction of an eCommerce site they were developing at university. This resulted in PHP v3.0, which is the beginning of the PHP we see in use today, with the Gutmans and Suraski engine at the centre of a coagulated, custom-modified collection of other libraries (predominantly C-based). Version 3.0 also heralded something of a rebranding exercise, with the letters PHP now standing, in inimitable unix-hacker style, for the compulsory recursive acronym "PHP Hypertext Preprocessor" which, the recursive element aside, is a far more accurate description of its v3.0 and v4.0 usage. Version 4.0 was the result of a rewrite of the core engine (now called the Zend engine - Zeev Suraski, Andi Gutmans) to enable even more breadth of use.
Zend is also the name of the resulting business established by Gutmans and Suraski, and Zend contributes engine development to the evolution of PHP, whilst selling proprietary database and optimization enhancements to paying customers. Meanwhile, the usual crew of disparate coders add other enhancements and library extensions. Hitherto, the saga has been a notable success in the blending of open source development and corporate interests. [3]
For PHP v5.0, Zend have done a second ground-up rewrite of the engine to allow for the swathe of new features; the new engine being the Zend engine v2.0. One observation of the new feature set is that they may need to 'rebrand' yet again: It is patently obvious that "Hypertext Preprocessing" is not solely what the latest modifications are geared towards.
A Pretty High-level Perspective of the Older Syntax (PHP v4)
The syntax of PHP looks like the offspring of a drunken alley-fondle between C and Perl. Given its heritage, this is hardly surprising. It is also another reason for its phenomenal popularity. Perl coders wouldn't dream of using anything else on a web server, but programmers familiar with any C-like language, and a basic understanding of HTML, HTTP and CGI, can get up to high speed with PHP very quickly, often in less than a day (feel free to make your own jokes about dealing with "write-only line noise" at this juncture)[4].
PHP was originally developed to be intermingled with HTML so it is encased in tags, much like ASP. To break into PHP the <?php tag is used and its sibling ?> tag is used to break back out. There is a short form of the opening tag ( <? ) which can be used if specified in the 'php.ini' configuration file. Likewise, ASP-style tags (<% and %>) can be used if configured similarly. If a lot of work with XML is being done, these alternatives may have to be used creatively to prevent certain kinds of parse error, although this often isn't a problem.
Comments can be either multi-line C-style (/* ... */), single-line Unix/Perl-style (# ...) or single-line C++-style (// ...) [5]. Like C, statements in PHP must be semi-colon-terminated (';') unless they occur immediately before the closing PHP tag, as this will automatically terminate the statement successfully.
Variables are weakly-typed and begin, scalar-perl-style, with the dollar-symbol, like so: $hello.
Basic integral values (0, 1, -255, 32768 etc.) are implemented behind the scenes as signed longs; Floating-point types (3133.7, -0.001, 3.141592 etc.) are implemented as doubles; Strings are implemented as custom-written structures; Everything else (objects, arrays etc.) is implemented using hash tables (aka. maps) [6]. All of this is transparent to the programmer and no knowledge of the underlying implementation is necessary to use the language itself. Variables inside double-quoted strings ("$x") will be expanded; those inside single-quoted ones ('$x') won't. The dot/period/full-stop character ('.') is used for concatenation.
This set-up has a number of advantages, including allowing for simple multi-dimensional arrays and type-agnostic array-storage. Arrays must be declared with either the array() function call, which provides an interface for both simple (value only) and complex (key and value - i.e. mapping) declarations, or using the traditional syntax with no call to array() necessary. In the latter case, if the specified key is not present it will be created, otherwise it will be over-written. For example:
$anInteger = 54321;
$aString = "Monkeys";
$compoundString = 'This is ' . 'a compou' . "nd string showing a monkey count. $aString : $anInteger";
$anObject = new TokenObject; // declared elsewhere...
$integerArray = array(5,4,3,2,1);
$stringArray = array("Just say no", "to", "working", "today");
$anotherIntegerArray = array(0 => 0, 1 => 1, 2 => 2, 3 => 3);
$integerMap = array("zero" => 0, "one" => 1, "two" => 2, "three" => 3);
$stringMap = array("Barcelona" => "Europe", "Seattle" => "North America", "Jaipur" => "India", "Washington" => "Another Planet");
$tradSyntax[0] = 99;
$tradSyntax[1] = "bottles";
$tradSyntax[2] = "of";
$tradSyntax[3] = "beer";
$tradSyntax['alternatives'] = array("urine", "peroxide");
$sillyDataStructure = array(
$anInteger, $aString, $compoundString, $anObject,
$integerArray, $stringArray, $anotherIntegerArray, $integerMap,
$stringMap, $tradSyntax
);
There are the usual cast of control-flow statements and operators, including a fully-working switch-case construct and bitwise manipulators. To get around some of the issues raised by using weak data typing in combination with C-based syntax and libraries, PHP introduces two new operators: "===" and "!==". These are equivalent to the standard equality operators ("==" and "!="), except that they take the underlying type of the variable into account. For example:
$someVar = 0;
if($someVar == false){ // ... TRUE - same binary value...
if($someVar === false){ // ... FALSE - testing against a boolean, but the variable is an integer...
// won't get here ...
}
}
These come in useful when using functions like strpos(), which will return false in the instance where the sought string is not found, but 0 in the instance where it is found at the very beginning of the string (offset 0). If tests using the normal equality operators were performed, it would be very easy to get the wrong impression.
The default behaviour of PHP is to let everything "fall through" to the default handler routines of the environment (most often Apache), except for content encased in the tags, which is parsed and executed via the engine. This feature can be 'abused' for structural or optimization purposes. As a very simple example:
<?php
// Some PHP code here ...
if(isset($someVar)){
// string is burped out by PHP ...
echo('<p>someVar <i>is</i> set.</p>');
}
else{
// break out of PHP...
?>
<!-- We're "in" Apache here - normal spit-out of HTML -->
<p>someVar <i>is not</i> set.</p>
<!-- Break back in to PHP -->
<?
}
?>
Functions are defined (not surprisingly) with the function keyword. By default, arguments are passed by value, although there is a similar syntax to C/C++ for passing by reference. C++-style "default arguments" are also featured. For readers unfamiliar with these: They are a way of stating a function's argument list so that, if the funtion is called with fewer than the declared number of arguments, the default is selected. It is a way of avoiding / improving on function overloading (which is supported in C++, Java and the new PHP v.5, but not PHP v.4). For example:
function insult($name = "Bob", $phrase = "Screw You"){
echo($phrase . " " . $name . "!\n");
}
Called without arguments, insult(); would print:
Screw You Bob!
Called like this:
insult("uid:3");
The following would be printed:
Screw You uid:3!
But, if called like this:
insult($anArbitraryDislike, "The zenith of the art of pig-humping has been achieved by");
Well, the output is fairly obvious...
There is an enormous, fully-developed standard API of functions for myriad purposes. C programmers will recognize many of the function calls and libraries involved due to the fact that extending PHP requires little more than specifying some custom headers (which export the library interface and act as intermediaries between the native C library and the Zend API), defining the function implementation within the bounds of the engine's thread-safe resource manager and then compiling accordingly.
Some functionality requires an external library to be present on the system, but PHP ships with 'versions' of many of these libraries built-in. On Unix systems, deciding what to include and what to exclude can often result in a ./configure statement of ten lines or more in length, and it's well worth saving it to a text file for future use when you've got it how you want it. On Microsoft Windows systems, these modules tend to ship as pre-built binary DLLs whose inclusion is achieved by uncommenting certain lines in the aforementioned 'php.ini' file. Similar modularization can be achieved on Unix systems, but most people statically compile the requested libraries directly into PHP (and some then statically compile PHP directly into Apache).
Providing Helpful Prerequisites - a quick deviation / crash-course about Object Orientation (OO)
For readers unfamiliar with object-orientation, the basic idea is that sequenced, procedural function calls are replaced by encapsulating most of your code into objects (classes). Objects contain their 'own' variables and functions (members). These objects can then be used, or 'hooked-up' with other objects, and use their own members to 'communicate' with each other.
On its own, this mechanism would offer only a slender syntactical advantage over encapsulated structural aggregations containing variables and function pointers (e.g. structs in C); and the very slight overhead involved in constructing the objects may cancel that advantage out. If it were just about code organization, object-orientation would be useful, but more than a little underwhelming (of course, the true hardcore proceduralists consider it so anyway). The main power of object orientation, however, comes through a concept called polymorphism.
Polymorphism relies on the idea of class hierarchies. For example; imagine a base class (an object at the top of the hierarchy) called Idiot. There could then be sub-classes (derived objects) of Idiot called InternetIdiot and Politician. InternetIdiot could, in turn, have sub-classes called Troll, Biter, LongScreedWriter etc. The key idea here, is that sub-classes inherit member variables and functions from their super-classes, but have the option of over-riding the members they inherit with implementations (function definitions) which are custom-designed to suit the purpose of the given object better.
Imagine Idiot has a member function called saySomethingStupid(), which causes the phrase "I am an Idiot." to be printed out.
InternetIdiot might then over-ride this function to print out "I am teh Lam3r!". In turn, Troll might over-ride this function to print out "-1, I just had an uncomfortable pooh!" instead, whereas Biter might over-ride this function to print out "You are wrong and I am right." etc. [7]
Let's say we write a function to take an Idiot as an argument. As an example (Using C++ in this specific instance):
void speech(Idiot* i){
if(i->canSpeak()){
i->saySomethingStupid();
}
}
What polymorphism means is that you can pass a pointer to any type of Idiot (an Idiot , or any of its sub-classes) into this function and the correct version of saySomethingStupid() will be called automatically for that particular kind of object. The function doesn't need to know the exact type of the argument; all it needs to know is that it's a kind of Idiot; polymorphism takes care of the rest. Part of the idea is to replace the endless chains of if-else and switch-case statements that pepper much procedural code by having the correct behaviour called at the point of use.
As ever, there are many variations, tricks and implementation details that complicate this idea, but that, in a nutshell, is what object-orientation is all about. Many programmers use object-orientation all of the time without even realizing it. Using some libraries, when you create an instance of, for example, a GUIWindow, it may itself be derived from a generalized GUIFrame object, which is in turn derived from an abstract GUIComponent. Part of the beauty of this mechanism is that the programmer doesn't necessarily need to know, but if they want to they can extend components themselves to add more options.
PHP v4 contains classes, primitive constructors, member variables and functions, basic polymorphism and primitive support for initialization. A full description would be far too large to entertain here but, seeing as most of the new features of PHP v.5 radically extend this functionality, and the object model has been completely rewritten from scratch for PHP v.5 (Zend Engine v.2), we'll do a quick drive-by in the next section. [8]
PHP Hits Puberty: The Next Generation (v5)
This section is intentionally terse, with fairly little explanation of the terms involved, as object-orientation is a massive subject; a behemoth; some would say a mess, and none of us want to be here all week (see Author's Comment).
Reading this, some programmers may well begin to surmise that Perl and C were not alone in that alley the night PHP was conceived; it seems to have been more of a threesome.
So what's new?
- Objects are now passed by 'handle' - This is a fancy way of saying that, in essence, they are passed by reference and not value.
- Object Cloning - this is implemented by the clone keyword. As soon as PHP v.5 decided to start passing objects by reference as a default, it had to implement some form of copy-constructor mechanism for those times when a programmer actually wanted a duplicate and not just another reference to the same object: This is it. Each object wishing to over-ride the default assignment semantics must implement a __clone() function. When the following occurs:
$monkey = new Character();
$pigsy = clone $monkey;
$monkey's __clone() function is called to produce a correct $pigsy. What counts as 'correct' depends on the context. A default __clone() function is applied by the system; once a programmer over-rides this function, they must take care of all the initialization for that object themselves.
- The instanceof keyword / operator - With vastly increased object-orientation capability, some form of cheap and cheerful run-time type identification was needed - this is it. It is similar to a simplified version of the typeid operator in C++.
- Reflection API - Reflection is a way of probing, examining and reverse-engineering classes, interfaces, functions as well as extensions, on the fly, at run-time. We won't go into the PHP Reflection API here, but its presence is noteworthy.
- Improved constructors and destructors - Constructors are functions which are used to initialize objects on instantiation. They are member functions of the class, and automatically run at creation-time to ensure a correctly-built object is present for safe usage. In PHP v4, constructors were fairly basic affairs, and didn't allow clean calls to the relevant superclass constructors; this has been improved. Objects constructed using the new constructor syntax need to include the double parenthesis '()' on the end of the call e.g. $anObject = new Thing(); - the old syntax does not require this. Destructors are new in PHP v5; they do the opposite of constructors, and allow an object to tidy up after itself when it falls out of scope or is destroyed (more on this later).
- private and protected member variables and functions for objects - private items can only be used by the object itself; protected items can only be used from the object itself and derived objects (subclasses of that class). This follows the C++ semantics for member access (no friends allowed, though), and not the slightly stranger Java semantics.
- abstract classes (and functions) - Abstract functions are object member functions which are declared but not defined. They provide a contractual interface / format for subclasses to adhere to and over-ride with the appropriate definition for that object. Abstract classes are classes which contain one or more abstract functions. They are intended for subclassing only and cannot be directly instantiated. They are declared as follows:
abstract class AbstractShouter{
abstract public function shout();
}
They can then be sub-classed using the extends keyword, something like this:
class AnnoyingGuyAtWork extends AbstractShouter{
public function shout(){
echo("GOOD MORNING WANKERS! I WENT TO ...<tune out...>");
}
}
- interfaces - Interfaces share a certain amount of functionality with abstract classes. They are designed to specify a programming interface which an implementing class guarantees to conform to. They contain function declarations (no definitions) and nothing else. In the case of abstract classes, the implementing class must be a derived class (subclass). Interfaces, on the other hand, can be implemented by any class. There are no limits to how many interfaces a given class can implement [9]. Interfaces are declared as follows:
interface Sleepable{
public function snooze();
}
A class can implement an interface by using the implements (d'oh!) keyword as follows:
class Couch implements Sleepable{
public function snooze(){
echo("zzzz...mmmm...comfy couch....zzzz");
}
}
- The final and constant keywords - final is used to specify that a member function of a given class cannot be over-ridden by a derived class. When applied to an entire class it means it cannot be subclassed. constant is applied to member variables of a given class. It means much what you'd expect - that the variable in question cannot be changed; previously, there was no way to protect a member variable in this manner.
- Exceptions - Exceptions are quite a large subject and we won't really go into them here (although you may well have seen the term on your Blue Screens of Death or crash windows). In short, they are a combination of a certain type of control-flow mechanism and objects conforming to a certain specification. When an error occurs, the program throws an object (the Exception) containing useful information about the error (often, simply the presence of the object is informative enough by itself). This object percolates down the stack where it can be caught by a dedicated catcher to handle the exceptional condition. If a suitable catcher is not found, the program terminates, often printing the occurence of the Exception to the screen.
For those familiar with Exceptions, PHP supports the usual try and catch blocks, and the throw keyword. Like C++, it does not support Java's finally clause. Exceptions are such a powerful mechanism that some programmers use them for general control-flow purposes, or message passing, and not for exceptional conditions. For various reasons (usually involving memory or unpredictable flow) this is generally considered Bad Practice® and should probably be avoided.
- static class functions - This means pretty much what it means in both Java and C++. That is: it is a function which is a member of a given class, but for which there is only one function in memory for all instances of that class - as opposed to all instances of that class having their own local copy. These are often referred to as class members as opposed to instance members.
What this means, in effect, is that you don't need to have an instance of the class containing the function to be able to call the function. Because of this, they are often used as 'Factory functions'; which are functions that produce fully-constructed objects for use in the calling scope. 'Factories' are generally classes that contain a number of static methods and act as "variable producers" to protect programmers from having to deal with the underlying implementation of a given object. They are often used when the language / interpreter concerned has to make a complex low-level call to the underlying operating system to retrieve some resource. For example:
$guiWindow = GUIFactory::giveMeAGUIWindowPlease();
- the __toString() function - When implemented for a given object, this function will be called whenever an echo, print or string-using function is used with this object. This means that when you call echo($myObject); a programmer-defined string (the return value of the __toString() function for the object in question) will be printed. This is similar to overloading the << and associated operators in C++, or implementing the bean-conformant toString() function in Java.
- Overloaded functions and accessors - Overloading is a way of providing functions of the same name, but with different argument lists, and having the right one called automatically depending on context. To be honest, I haven't had time to figure out the syntax of PHP v5's take on this yet. It looks a lot more clumsy and hackish at first glance than the Java or C++ equivalents, and seems to work via an implied rather than an explicit call. In truth, it's not often needed due to PHP supporting C++-style 'default arguments', but I'll have to reserve judgement until I fully understand it.
- Altered string indexing syntax - In previous versions of PHP, you could access a character of a string by using the array indexing notation so that, given:
$aString = "monkey";
$aString[0] = "d";
$aString would then contain "donkey". This was confusing and erratic. It was unclear as to whether you were changing the character at the specified offset, or redefining $aString to be a general array with the string "d" at offset 0 (to C programmers, this would be similar to the difference between a char and a char* at the given offset). The new syntax uses curly brackets {} for string subscripting and square brackets [] for arrays.
That ends the whirlwind tour. There are more new developments than have been mentioned here, but these are the most significant.
Philosophizing and Hasty Prose
The first question that springs to mind is: "Does any of this look familiar to any of you?"
Upon encountering the revisions for the first time, my immediate thought was "Hang on; I thought this was PHP". To cut to the chase: It looks almost exactly like Java!
This isn't necessarily a bad thing. Java is an incredibly easy language to write (some claim too easy), and borrowing ideas from other languages is an idea as old as the hills. Bjarne Stroustrup freely admits borrowing most of C++ from C and Simula; Larry Wall (Perl) likewise with sed, awk and shell scripts. The more interesting facets arise when you consider exactly what the point of the whole deal is, though.
i. The Backdrop
I've always been slightly dismissive of using anything more than minimal object-orientation in PHP (and bear in mind that it's C++ and Java which put most of the bread on my table). This has largely been as a result of how PHP works and the way it has been used traditionally.
Usually, PHP has always been deployed as a web-server scripting language. When a request hits the server, the file is opened and parsed through the engine, any necessary extra files are include()ed or require()ed, the localized stack is built, the code executed, the stack collapsed, the content delivered back to the server and thence the client. In this context, heavy use of object-orientation seemed somewhat excessive given that the constructed memory was destroyed at the end of the request chain and would have to be built afresh on each page hit. This means that you have to build a base class, then the derived classes, then use them, then they die: Rinse and repeat. There was no easy mechanism through which to have complex, global, persistent objects hanging around in memory (which would have raised concurrency issues anyway - different requests competing for the same resource).
Using sessions (especially sessions in shared memory or database-driven sessions), or newer technologies like memcached, can alleviate this burden to a fairly large extent [10], but this is still a distance away, functionality-wise, from the way in which Perl and C Modules work. PHP itself is an Apache module, and you script 'to' that module. Perl and C modules act at a lower part of the chain, by being modules themselves and plugging directly into Apache's request cycle as content handlers at any one of the necessary phases. This doesn't necessarily mean that one is better than the other, just that replicating some specific functionality offered by Perl in PHP is difficult, unless you compile-in a custom-built extension yourself which, whilst not rocket science, is not 'trivial' [11].
Things being such, I could only ever see PHP's object-orientation support being useful in the context of encapsulation, aggregation and code organization. Polymorphism of any great complexity seemed to be an unnecessary waste of cycles when compared with the equally-valid procedural equivalent. Of course; this is a criticism which gets levelled at all object-orientation to some degree, but it is not particularly valid. It might vaguely be valid only in contexts where both the objects themselves cannot be preserved and reused, and where blinding speed is imperative (in which case it might be time to break out the assembler anyway). In most other instances, the decisive factor is the decency of the relevant compiler.
The truth of the matter is that situations in which efficiency is of paramount importance are becoming increasingly few. Most desktop computers these days have cycles to burn by the truckload. Varieties of server, games, real-time multimedia manipulation and certain brute-force questions (weather and particle-physics modelling particularly) are some of few domains left where anal attention to speed is the primary criterion. The "speed standard" for the vast majority of other applications is "fast enough". In the instance where you run up against the ceiling of performance, the standard solution is "more hardware" (most weather-modelling isn't done on power-books - yet). This can be evidenced by humble Kuro5hin itself. People point at the MySQL database as being the bottleneck and "not as efficient as x"; strangely, this doesn't seem to bother Slashdot - but look at Slashdot's hardware specs! In short: It's not the database engine.
A server servicing multiple clients with heavy requests is, however, one of the contexts mentioned above, and the upshot of this is that, in certain circumstances, on a webserver, heavy use of PHP's polymorphism can be profligate.
In the interests of honesty; the efficiency and 'relevance' factors were not the only things which were mild irritants about PHP's object orientation. To cap it all off, the syntax was bordering on 'cludgy' as well. I concede this is a highly subjective opinion, but if you're going to borrow syntactic contructs from C and C++; at least make them work as similarly as possible.
ii. The Update
As with any techie whose work involves a given field, I was curious enough to see what the much-vaunted rewrite of PHP would yield. Being busy with other projects when the announcement and early development releases were made, the first concrete information I became aware of was when a friend (primarily a PHP developer) wrote to me a few months ago, quite excited, to outline the new developments, send some sample code and provide links to the relevant URLs. Unhealthily interested myself, I dived into the information (beats working...) and had a total brain freeze:
"W.T.F.?"
The part of PHP which I'd always had the least respect for was the part they'd gone to great lengths to extend. Not only that, but they'd rewritten the engine just to support this new expansion. Looking for any non-object-orientation-geared improvements, the only solace to be found was in the aforementioned change to string indexing. In addition to this, they seemed to have stolen most of what syntactically made Java, well, Java; and even the implementation of that seemed to resonate with the syntactic deviations they'd made from C/C++ in the more simplistic object orientation of PHP v4. My reaction was one of mild distaste. Why hack this unnecessary rubbish on to something of which simplicity was always its strongest feature? Merde. [12]
Certain aspects of the implementation began to raise questions. Destructors ? What the hell did they want destructors for? In C++, destructors are mainly used for freeing heap memory which has been manually allocated. If you put the delete or (much less commonly) free calls inside the destructor of a class, you can get it to mop up for itself, the freeing of extra memory is not required - this is pretty much the entire point of destructors. Java uses garbage collection so destructors aren't needed. PHP requires it even less - it is self-mopping in the underlying implementation. PHP.net's own documents write:
"Destructors can log messages for debugging, close database connections and do other clean-up work.".
Well ... I guess ... , but this doesn't seem to offer that much of an advantage over using straight functions. Since v3.0.4 there has a way to specify code to run on request shutdown: register_shutdown_function() behaves in a very similar way to C's atexit() function; registering callbacks to run on termination. In C++ you get some clear tangible benefit from destructors: Build the memory acquisition into the constructor, the memory deallocation into the destructor, and you can pretty much fire-and-forget forever more - it takes care of itself. [13]
In PHP it all seemed so...superfluous: Sure; you can use destructors to close file handles and database connections, but they are no real pain to tidy up manually and, should you forget, unless specifically told otherwise, PHP will close these automatically at the end of the script anyway.
Similar thoughts occurred about some of the other features.
After being mildly glum for all of about eight seconds, the consolation occurred that hey, like C++, at least they didn't force the object-orientation on you; it was there to be used or ignored, as is seen fit. Granted, there were no real improvements from a personal perspective, but they hadn't destroyed any of the things which were good about it, either. I got back to work.
I was slow on the uptake. At lunchtime, the sinister Pinky-and-the-Brain reality finally dawned ...
THEY'RE TRYING TO TAKE OVER THE WORLD!!!!
iii. Dietrologia and Speculation, from the trenches
OK; perhaps accusing them of a covert attempt at global domination is over-cooking it a bit. What seems clear, at least from my perspective, is that the PHP developers are no longer thinking of the webserver as the only 'domain space' for PHP as a product of great utility.
It probably isn't putting it too strongly to state that PHP v5 represents a concerted attempt to break away from the role of 'easy-server-side-scripter', with competing in the role of an all-purpose, easy-to-program, generalized, cross-platform interpreted language being the ultimate aim. They're not just borrowing syntax from Java; Long-term, they're actually going after Java's market niche, and Perl's, and Python's, and dotNET's, and VB's...
When looked at like this, the new enhancements are completely consistent. Elaborate polymorphic programming really doesn't make for a marked improvement, or even a great deal of sense, when used in the create->deliver->kill context of web-page delivery, but it makes an awful lot of sense when viewed from the perspective of a generalized language, supporting large, complex, modular applications that may be running for a considerable length of time. A lot of those features aren't there for convenience; they're there for forward-compatibility; uses which haven't necessarily been dreamed up yet. PHP v5 is not a major-version upgrade so much as a revised statement of intent.
"Looks like a duck; quacks like a duck" abductive reasoning aside, is there any actual evidence that this is what the developers are attempting?
Well, yes and no. The improved object model means that a new level of integration with other technologies is possible, and there are new libraries for COM and dotNET, Java, XML, and Perl. Integration with native code has already been achieved. As previously mentioned, extension libraries can be compiled, fairly easily, directly into PHP itself OR, somewhat in the style of Perl's XS, they can be compiled as external shared library *.so's and either loaded dynamically using the dl() function at run-time, or loaded on process start by configuring the correct options in the ubiquitous 'php.ini' file.
Zeev Suraski, in a high-level overview at Zend.com has written:
" The release of PHP 5.0, powered by the Zend Engine 2.0, will mark a significant step forward in PHP's evolution as one of the key Web platforms in the world today."
It is evident, then, that in the short-to-medium term, the web is still PHP's main battle-ground, although its reach has increased considerably. Its authors now place it firmly in the category of 'platform' rather than 'scripting engine'. This is increasingly a "web world", so it's no surprise that PHP is trying to consolidate and expand on its home turf. What with the creeping sprawl of Java and dotNet in the enterprise market, it was always going to have to do something to catch up / stay ahead / keep pace. But what evidence is there that it may intend to move off the webserver and into the client space?
A surprising number of interesting things are going on in this area.
Probably the most significant development so far was the release of the PHP CLI SAPI module in v4.3.0. This is a binary executable which sits in $installation_prefix/bin (or the relevant installation folder on Windows systems) and behaves in much the same way as the Perl and Python binaries. It supports the running of files which begin with the standard #!/path/to/interpreter syntax, and has a number of command-line switches / flags. 'Neat code' can be executed in a similar manner to the 'perl -e' command, except the 'php -r' command is used instead.
In PHP v5 they've taken the idea a stage further for Windows systems, with a php-win.exe, which is an analog of Java's javaw.exe. This provides the same functionality as the CLI binary, except no console window is needed or popped-up at run-time, and applications / scripts can write directly to and from this executable behind the scenes (this ability isn't needed on Unix systems due to differences in the process control mechanisms).
So the interface for client side applications is already in place. On top of this there have been extensions to the standard API to provide bindings for the Ncurses and Readline libraries. Perhaps the most ambitious binding project undertaken so far is the PHP-GTK project. The bindings for GTK-1 are stable and complete, and work is in progress on writing the bindings between PHP v5 and GTK-2.
So, to the logical question: Have any significant client-side applications been written in PHP?
No; and a quick perusal of the application pages at PHP-GTK and SourceForge suggests it may be a long while yet before we see any. A number of small applications for very specific purposes have been written, and it is perhaps in this field in which client-based PHP will always stay, although perhaps not...
iv. The Shape Of Things To Come ?
The first point to be considered is that, to genuinely extend its grasp, PHP doesn't need to move off the webserver that much. The truth of Sun's high-profile assertion that "The network is the computer", whilst much derided at the time, has become increasingly evident over the years. The current 'hype application du jour' is undoubtedly Gmail: a web-based email application. The browser is becoming increasingly important as network-application-client cast against its more tradional role as remote-document-viewer. Don't argue; The fact you're even reading this is half-proof in itself: Scoop is a content-management application.
Think of the things already possible via a browser: Games, Audio, Video, Animation, Communication, Creative and factual writing, Trade etc. Granted, it's not like you can play GTA: Vice City, or edit real-time high-resolution video yet, but is the day really that far off? It's simply a question of ease-of-use, bandwidth, economics and will. Joel Spolsky deals with this whole issue in last month's excellent article, "How Microsoft Lost the API War".
The second point is that not only is this increasingly a networked world, it's also becoming more and more of an "interpreted world"; by which I mean that many new applications are being developed in non-natively-compiled languages.
Along with PHP, Python has seen an extraordinary amount of growth in the last few years; Perl and Java are being used more than ever, and we've seen the entrance of C#, the new Visual Basic, dot Net, and the whole Common-Language-Infrastructure scenario [14]. This is partly as a direct result of the burgeoning interconnectivity of computing power (it doesn't help that all the variant operating systems and hardware are online, if they can't talk to each other in any useful way) and partly as a result of the ever-onward march of Moore's Law - we're a fair way from the limits of current chip technology yet. Of course, these drivers of change feed back upon each other to an extent.
For pretty much the first time in computing history, applications coded to a virtual machine or interpreter (there is a difference, John Udell) now run faster than they did in native form just a few years ago, and they are only going to accelerate and get more efficient over time. As somebody who actually enjoys C and C++, this both makes me a little sad and brings out a sense of slightly rebellious longing. The idea that two of my favourite languages might, in just a few short years, occupy the same niche that Assembly and Cobol do today is not a particularly comfortable thought. It's never pleasant to contemplate obsolescence, but then: That's evolution. No prisoners.
Stretching the point even further, it's not too far beyond the bounds of realistic speculation to envisage a situation where native, compiled code's only function is to act as a thin gateway to hardware (which, as ever, is the one fixed immovable); upon which the operating system itself would be both a general interpreter and, for the most part, interpreted. Whilst almost inconceivable in the current climate, this would have a dramatic effect on the business, usage and adaptability of all information technology infrastructure as we know it today.
Perhaps it is not intentional, but nevertheless it is this world that PHP is adapting to. Whether it can continue to compete in its current guise is a question only the future can answer. Like HTML, its overwhelming success has come about from its shallow learning curve and ease-of-use. Like HTML, its days are numbered unless it can evolve to be more complex. As the hacker deity in Neil Gaiman's "American Gods" pronounces: "It's all about the dominant fucking paradigm ... nothing else is important". Without really noticing and with all marketing hype cast aside for a moment, at some point in the last few years we really did cross the threshold: The next age is already here.
----------
NOTES
[1] - There are two points to be considered here.
The first is that determining module usage by analysis of server output (usually the HTTP response headers) is at best an inexact science. Nearly all Apache modules provide some facility for concealing their presence on a server, usually for security-through-obscurity reasons. Concealing PHP is simply a case of setting 'expose_php = Off' in the 'php.ini' file and (somewhat self-evidently) changing 'AddType application/x-httpd-php' to be something other than a '.php' suffix in 'httpd.conf' (a popular option is specifying '.htm' to be processed as PHP and allowing '.html' to be content-handled normally), although most sensible developers are aware that, where servers are concerned, the file suffix doesn't necessarily tell you anything useful. Preventing mod_perl from announcing its presence requires a very lightweight hack to the C source code. There are also countless other methods, including changing Apache's 'ServerTokens' configuration, and running proxy / frontend servers . In short: it's very hard to get demonstrably reliable data by examining server response headers.
For those who are interested, these HTTP responses, although usually invisible to the end-client, can be seen by various means. Telnet-ing to port 80 and issuing a correctly-formatted HEAD request (behave...) will do it, although the Lynx text browser provides a more convenient method, and doing a "View > View Document Information" in Konqueror will also show them, albeit in a reformatted layout. Using Lynx's '-head' and '-mime_header' switches in combination will return the information of a HEAD request, whilst preventing you from entering 'browsing' mode unnecessarily. For example, here are some server response headers from a couple of familiar websites:
> lynx -head -mime_header http://www.kuro5hin.org
HTTP/1.1 200 OK
Date: Wed, 14 Jul 2004 22:20:37 GMT
Server: Apache/1.3.23 (Unix) mod_gzip/1.3.19.1a mod_ssl/2.8.6 OpenSSL/0.9.6a
Cache-control: no-cache
Content-Length: 60842
Content-Type: text/html; charset=ISO-8859-1
Expires: Wed, 14 Jul 2004 22:20:37 GMT
Pragma: no-cache
X-Cache: MISS from www.kuro5hin.org
Connection: close
> lynx -head -mime_header http://www.hulver.com/scoop/
HTTP/1.1 200 OK
Date: Wed, 14 Jul 2004 22:22:04 GMT
Server: Apache/1.3.29 (Unix) mod_perl/1.29
Vary: Host
Cache-control: no-cache
Pragma: no-cache
Content-Length: 35423
Content-Type: text/html; charset=ISO-8859-1
Expires: Wed, 14 Jul 2004 22:22:05 GMT
X-Cache: MISS from www.hulver.com
Connection: close
The sharp-eyed will notice that K5's response header makes no mention of mod_perl at all, although K5 is undoubtedly using it (unless the developers have retooled the entirity of Scoop in C, which is a tad unlikely). This exemplifies the inaccuracy mentioned above. The even-sharper-eyed may note that the version of OpenSSL being used is a few Security Advisories behind the times and, in the spirit of open source development, may wish to mention this to the administration...
The second point to be considered becomes self-evident when taking a moment to contemplate the cavernous gulf in reality between development using any programming language, and the soft-focused, pornesque cheerleaders (*pause - look heavenward - stroke chin - or...otherwise...*).
[2] - Some interesting, and slightly odd, information regarding the uniquely quaint and charming British slang phrase "to take the piss" / "taking the piss" can be found here. In all recent contexts, it is loosely equivalent to "making fun of", satirizing, or "having a laugh at a given person's expense". It is not recommended for use in meetings with executives.
[3] - This is very much a digested history. More accurate details are available from the history page of PHP's exemplary manual. It deserves to be mentioned that the manual itself is so damn good that it's pretty much all you need to learn PHP from scratch - and is at least partially responsible for PHP's explosive growth.
[4] - I did try to find a nice piece of suitably-obfuscated, illustrative scoop-code at this point but, (un)fortunately, Scoop is written with surprising clarity (given the nature of the language and the perl hacker's suspect psychology). :-∫
[5] - A nasty little 'feature' of PHP comments is that the single-line versions "comment to the end of the line or the current block of PHP code, whichever comes first " (manual - comments). This means that you cannot use these to comment out a closing PHP tag (?>), or comment out a string containing anything which might match the tag (e.g. XML, regular expressions) and expect it to work correctly. This can be an odd 'feature' to catch, as a line of code which, when uncommented, works perfectly (parses as a string) can often cause the script to break when commented out (parses as a breakout tag) ! The reason for this is because of a fundamental semantic collision between HTML and the newline character. HTML considers the newline character to be semantically meaningless, and in order to facilitate web-designer usage such as -
<p>Hello <? echo($name) ?>. We are <? echo($b0rked) #server error... ?>. Please call back later.</p>
- either the newline had to be made semantically meaningful (which confuses web-monkeys) or the closing PHP tag had to take precedence (which confuses programmers). Web-monkeys are more important than programmers, it seems (yes - it did catch me out once). To get around this, use the C-style multi-line comments instead.
[6] - This is a very terse and slightly inaccurate description of the underlying implementation. Most of the internal definitions are abstracted away using Zend-engine-specific macros and functions. C programmers wanting more details on the 'nuts-and-bolts', and on developing for mod_php itself (adding extensions and extra features etc.) should consult the Zend API section of the manual.
[7] - LongScreedWriter would probably print out this entire article.
[8] - For those interested in the specifc details of PHP v5, php.net has put up a web-page describing the new PHP object-oriented features and syntax which gives a much more thorough (better) flyby than that provided here. Zend have provided a 37-page PDF outlining the new features more fully, although some of this is slightly out of date (for example, they have dropped multiple inheritance in favour of interfaces, and appear to have ditched the delete keyword).
[9] - C++ supports multple inheritance (allowing a class to have more than one direct parent or super-class), so interfaces are not necessary as a core language facility (although programmers can, and do, write their own). PHP and Java, on the other hand, do not allow multiple inheritance (although it was considered for PHPv5) and thus the interface mechanism allows for the flexibility of multiple inheritance without any of its associated 'issues'.
[10] - Incidentally, this is one of the areas for which Zend sells (fairly expensive) proprietary extensions.
[11] - I have no wish to reignite the PHP vs. mod_perl debate; it was stale when mammoth-steak was at the top of the menu and, as Marshall Cline has put it, that kind of argument "generates far more heat than light". They both work superbly and each has advantages over the other. The only thing being discussed is the merit, or lack thereof, of using procedural PHP versus object-oriented PHP on a webserver. Likewise; please note that I'm not saying that "you can't do something in x as well as you can in y". The point is very specific, which is that "you can't do what x does, the exact way x does it , in y", with no superiority / inferiority implied. Whew.
[12] - It transpires that I was in no way alone in this thinking.
[13] - This is a small part of what is often referred to as the 'Resource Acquisition Is Initialization' idiom or technique (pithy name, huh?). It's a key idea in C++, and accounts for a number of issues, including exactly why C++ doesn't have a finally construct in its exception-handling repertoire.
[14] - Whilst many will deride these last examples as both platform and vendor specific, it should not be forgotten that both C# and the Common Language Infrastructure have been standardized (something Sun have not done, and indeed indicated they are not prepared to do, with Java), and that there is a practically fully-functional implementation already available for Linux systems.
![]](/web/20051204201833im_/http://www.kuro5hin.org/images/header/rt_edge3.gif){kind=small}
![[XML]](/web/20051204201833im_/http://www.kuro5hin.org/images/rssblue.gif){kind=small}
![[P]](/web/20051204201833im_/http://www.kuro5hin.org/images/print3.gif){kind=small}
