We recently tapped PHPCon Speaker, Sterling Hughes who took time out from preparing this talks on PHP & XML and Top 7 Mistakes in PHP Programming to discuss the upcoming release of PHP5. Bryan Richard, Conference Director for QuarterPower Media, conducted the interview via email.

Bryan Richard (BR): Please introduce yourself and tell the good people why we are talking to you about PHP.

Sterling Hughes (SH): Hi, I'm Sterling. I'm the author of the "PHP Developer's Cookbook," and I've been using PHP since version 3 and a developer of PHP since before the first beta of PHP4. You may know me as one of the authors of the cURL, XSLT, Bzip2, Zip, Sockets, Cyrus, SWF, ADT, Mono or dio extensions.

BR: You recently delivered a presentation to NYPHP on what's new in PHP5. Is 5 something to get excited about? Are these big changes?

SH: Well, that really all depends on who you are. Personally, while I have programmed with both C++ and Java, I am mostly a procedural guy. I feel that most object oriented programming consists of abstracting different problems into the same problem and then resolving that problem. Sure it makes it easier, but its incredibly inefficient for developing a small set of interconnected programs, which really is the whole point in web development.

That's not to say I'm unhappy with PHP5. Most of the stuff in PHP5 is great, most notably exceptions; I'll certainly be taking advantage of many of the new features in Zend Engine 2. But most of my code is procedural, and Zend Engine 2 is mostly an object oriented functionality upgrade.

That's me. Ho Hum.

However, if you are a programmer who develops object oriented solutions, PHP5 is a reason to rejoice. PHP4 didn't really have an object model. Objects were base types, which internally consisted of two symbol tables, a table of functions and a table of variables. This meant that objects were unpredictable, unintuitive, and hard to efficiently implement. The ugliest symptom of this was whenever you used objects you had to pass them by reference.

Take the following code:

<?php
class Slowpoke {
    var $feet;
    var $arms;
}

$s = new Slowpoke;
?>

In PHP4, that code would cause a double copy of the object upon instantiation. To properly instantiate an object in PHP4, you had to prefix it with the '&' sign:

$s = &new Slowpoke;

This also applied to normal usage of the object:

<?php
function add_feet($s) {
    $s->feet = 2;
}

$s = &new Slowpoke;
var_dump($s->feet);
add_feet($s);
var_dump($s->feet);
?>

Here you wouldn't actually have changed the Slowpoke object, when you assigned '2' to the property 'feet' in the 'add_feet' function. Variables in PHP are copy-on-write, and therefore, unless you always pass objects by reference, when the object (or object properties) are changed, it is copied onto a new object.

In PHP5 however, objects are references by default, a huge win as far as sanity is concerned. Instead of passing around the object itself, you pass around an integer which identifies the object to the engine. When the object is accessed, the object corresponding to that integer is retrieved. This will help improve performance in a large number of PHP scripts which misunderstood PHP4's object model. The naive implementations of the above two scripts works perfectly with PHP5.

BR: If you feel that OOP is inefficient for solving web problems, why does it seem to be the focal point of the new release? Is PHP trying to become more of a general purpose language like Perl, Python, or Ruby?

SH: Everyone has their preference. My personal preference is to use procedural paradigms, except when encapsulating nouns. In other words, when I want to describe an object, I use objects. :) What I object to is people who use OO to develop large, overly-abstracted reusable frameworks, encapsulating all their logic within the object itself. These frameworks, especially in the webspace, tend to be more complex than the problem they originally set out to solve.

With that said, I believe object orientation was the focus of the PHP5 release for two reasons:

1. It sucked in PHP4. PHP4 handled procedural paradigms flawlessly so there wasn't a need to evolve in that area, however, as I've mentioned elsewhere, PHP4 didn't really even have an object model. Zeev described the design and implementation of PHP4's object model most aptly as the result of "one restless night."
   
   
2. Some people like large object oriented frameworks, different strokes for different folks.

BR: PHP developers and site admins have had to undergo big changes in the past -- register globals being turned off by default comes to mind. Do you think the amount of language restructuring will cause a user backlash like what was seen with Visual Basic when Microsoft tried to force VB.NET on developers?

SH: PHP5 is an evolution, not a revolution. Probably the one thing all PHP developer's pride themselves on is pragmatism. Unlike other languages, PHP puts paramount importance on maintaining backwards compatibility. Not only will PHP5 have a set of ini options that will virtually eliminate backwards compatibility issues, but the changes are, for the most part harmless, as old syntaxes are supported.

BR: Your presentation does a good job of outlining the upcoming features but I'd like to get your impression on a few of them. Is this real PHP OO? Do you like how it was implemented?

SH: Defining "Real" OO is difficult, it has a different meaning for everyone. I certainly have nothing but good things to say about the new object model, and the implementation. When I was writing the Mono extension, I was able to witness just how far the object model has come. Andi, Stas and Zeev have done an incredible job with Zend Engine 2.

BR: try/catch/throw expectations?

SH: Try, catch and throw will be, in my opinion, the most useful feature of PHP5. Developing web applications is all about dealing with external data sources: a RDBM, a SOAP transaction, the filesystem, etc. This implies quite a bit of error checking, and with PHP4 you needed to constantly check for errors:

<?php
$fp = fopen("somefile", "w");
if (!is_resource($fp)) {
    die("Couldn't open somefile!");
}
fwrite($fp, "foo");
if (!fclose($fp)) {
    die("Couldn't close somefile!");
}
?>

In PHP5, exceptions will allow you to (optionally) simplify your code, moving all the error handling logic into one place:

<?php
try {
    $fp = fopen("somefile", "w");
    fwrite($fp, "foo");
    fclose($fp);
} catch (Exception $e) {
    echo $e->getMessage();
}
?>

SH: Autoloading?

SH: Autoloading is neat. I'm not too sure how useful it is, but it sure is nice.

BR: SPL?

SH: SPL is a testament to the extensibility of Zend Engine 2. SPL is an optional extension to Zend Engine 2 that defines a standard set of interfaces. Your object implements a given SPL interface, and then when your object is accessed via PHP builtin constructs the various methods defined by the interface are called.

SPL itself is syntactic sugar. Its not going to help you get your job done, and it'll probably confuse the heck out of people working with your code. But SPL is a great example of an extension taking advantage of the new internal features of Zend Engine 2, creating custom opcodes and overriding preexisting opcodes. Opcodes are sets of instructions that your PHP script compiles down to. Take the following PHP code:

<?php
$a = "Hello";
$b = "World";

echo $a;
echo $b;
?>

Under the hood, it gets translated into the following set of instructions:

0  FETCH_W   $0, 'a'
1  ASSIGN    $0, 'Hello'
2  FETCH_W   $72, 'b'
3  ASSIGN    $72, 'World'
4  FETCH_R   $144, 'a'
5  ECHO      $144
6  FETCH_R   $180, 'b'
7  ECHO      $180
8  RETURN    1

PHP opcodes are in the form of P-Code (aka, three address code), in which every operation corresponds to two operands and a result. With PHP4's architecture all execution occurred inside a huge switch loop, where each case corresponded with an opcode, such as RETURN, ASSIGN or ECHO. Having all opcodes hardcoded into a switch() loop made it impossible for one to override preexisting OP codes, and inefficient for one to add new OP codes.

In PHP5 opcodes are stored in an array, therefore you can override existing opcodes, and you can register new opcodes. This allows a great amount of power from within extensions, whether you're developing a debugger or something like SPL, which overloads standard array operators like foreach and the [] accessors.

BR: You touch on runtime overloading via __call() and Interfaces but you didn't really talk much about basic single and multiple inheritance. Is multiple inheritance supported?

SH: Classes can inherit multiple contracts via interfaces, so I guess you could call that multiple inheritance (Java programmers certainly do). However, multiple inheritance ala C++ is not supported. I personally like the idea of inheriting functionality as well as responsibility, however, after all, this is web scripting. Interfaces will give you a reasonable 95% of what most people want, and simplicity is the greater virtue.

BR: What do you think is going to pose the biggest problem for developers moving from PHP4 to PHP5?

SH: PHP5 is pretty much backwards compatible with PHP4, however there are a few changes to be aware of:

1. Because in PHP5 objects are automatically references. Code that relies on objects being copied by default, will have problems. Luckily, this is a relatively small amount of code, as dragging an object copy around was rarely what you wanted.
   
   When porting to PHP5, you have two options. The first, and prefered option is to use the __clone() accessor which forces an object copy:

   $o2 = $o1->__clone();
   

   It should be noted that clone is a much more reliable way of copying objects. In PHP4 you had all sorts of funky mishaps that occured when objects were improperly copied. You had to have an intimate knowledge of reference counting, and how PHP's copy-on-write mechanisms worked in order to properly clone an object.
   
   If you want your code to run unmodified, PHP5 also introduces a php.ini option called ze2.implicit_clone. When this is set to true, PHP5 objects behave like they did in PHP4, but you still gain the add features in php5, like unified constructors, namespaces, exceptions, etc.
   
   
2. Object properties must be pre-declared. In PHP4 the following code was perfectly acceptable:

   
   <?php
   class Container {
   }
   
   $c = &new Container;
   $c->name = "Sterling";
   echo $c->name;
   ?>
   
   

   In PHP5, however, the above is not possible. This decision was made because it made the implementation signifigantly harder and, further, its simply poor practice. If you want to dynamically define properties, you probably want to be using an associative array instead.
   
   To get around this BC break, you need to rewrite your object code to use overloading. Dynamic property assignment can easily simulate via PHP's object overloading:

   
   <?php
   class Container {
       private $props;
   
       function __get($name) {
           return $this->props[$name];
       }
   
       function __set($name, $value) {
           $this->props[$name] = $value;
       }
   }
   
   $c = new Container;
   $c->name = "Sterling";
   echo $c->name;
   ?>
   
   

3. You must declare classes before extending them. In PHP4 the following:

   
   <?php
   class foo extends bar { }
   class bar { }
   ?>
   
   

   Was possible. In PHP5, you must always declare classes before using them:

   
   <?php
   class bar { }
   class foo extends bar { }
   ?>
   
   

4. The following words are now reserved: try, catch, throw, exception, public, private, protected, abstract, interface, final.
   
   
5. Within the context of a class, the following function names are also now reserved: __call, __get, __set, __clone, __construct, __destruct.

BR: Developers have always been able to play fast and loose with access control. Do you think public, private and protected variables are going to be a stumbling block?

SH: I don't believe so. Private, Protected and Public are all about information hiding (enforcing a contract), and PHP programmers already have developed different methods for specifying such contracts. Whether it's prefixing private variables and functions with an underscore, or adding documentation stating the access level.

The private, protected and public keywords now give one the ability to programatically enforce a contract, however, the contracts have always existed. By default (if you don't specify public, private or protected), things will work as they did in PHP4.

BR: Your blog was Slashdotted recently. That must have been fun. Were you running 5 at the time?

SH: No, my weblog runs MovableType (soon to be changed to serendipity and my webserver runs PHP 4.2.2. The presentation system, however, was running PHP5.

BR: You mentioned on your blog that 5 seems to have some memory problems. How bad is it?

SH: Pretty awful. The presentation was graciously hosted by NYPHP, and we had to take it down while being slashdotted. PHP5 leaked so much memory we needed to set Apache's MaxClients to 25, otherwise the apache process size would go above 40 mb per child.

PHP5 is, at this point, pre-beta software. So memory leaks, crashes and bugs are expected. PHP5 will have a lengthy QA process that will hopefully remove all major bugs before it is officially released.

BR: How does the QA process work? Can the community get involved?

SH: We should be releasing a beta of PHP5 shortly, after that, it is a matter of testing, and filing bug reports (http://bugs.php.net/) with small, easily reproducable test cases. If you want to dedicate some effort to bug testing and fixing, join the PHP QA team.

The PHP release process works as follows (this all happens after the beta period is over):

a) Somebody decides it's time to make a new release, they send a message to the development list stating their intentions. If a lazy consensus is reached, they go ahead and create a release branch. This release branch can now only contain bug fixes.

b) They release a release candidate. A release candidate (unlike a beta), is a final version of the release, minus any bugfixes that might occur. This release candidate is tested extensively by the developers and QA team, as well as any adventurous users (release candidates are usually announced on the PHP homepage). Bugs that must be fixed before the release are marked as critical, and critical bugs are squashed.

c) After a few release candidates, and all the critical bugs are closed, someone rolls a final release candidate. This release candidate is the final version of PHP5 itself, unless any major showstoppers are found. This final release candidate is stress tested by the developers and the QA team. If no serious bugs are found, it is renamed and released as PHP5.

BR: Is the OO implimentation in 5 going to slow down code or can we expect to see performance gains?

SH: Both. :)

Strictly speaking PHP5 OO will be slower than PHP4 OO. This is partly due to the overhead of using object handles, and partly due to some of the marginal new features (like interfaces). However, using the object model will be much saner with PHP5 than with PHP4. Most PHP4 code will work better/faster with PHP5's object model, because not that many people were familair with how objects actually worked with PHP4.

BR: cURL now is bundled. You must be happy about that.

SH: No compliants. :)

BR: Ben Shepherd of DevArticles.com has a subhead in his "What to Expect in PHP 5.0" article titled "PHP 5.0 Will Take the World by Storm." I think PHP has already done a pretty good job of that but do you agree with Shepherd's statement? Is 5 going to tempt Java, C#, or Perl developers?

SH: I agree with you, PHP4 took the world by storm. PHP5 is a functionality upgrade, especially for people needing an object oriented "fix." I think the major thing you'll see emerging from PHP5 is the growth of PEAR. PEAR has always relied on a lot of kludges in order to maintain a coherent OO framework. PHP5 adds the features necessary to have a very clean implementation of the PEAR framework and the surrounding functionality.

BR: What would you like to have seen in 5 that isn't going to be there?

SH: A better XML extension.

Our thanks to Sterling for his detailed answers. Want to ask Sterling your own questions? Meet him at PHPCon East 2003.

Want to know when new interviews are available? Sign up for the PHPCon Announce list and stay up-to-date.