PHP5: Coming Soon to a Webserver Near You

Type Hinting

It may come as a surprise to you to hear that, by some definitions, PHP is a strongly typed language (other definitions call it weakly typed). PHP isn't a typeless language (which would mean it had no types at all). It has types such as string, int, array, object, etc.

Where PHP differs from languages like Java and C++, which are statically typed (types must be identified in the source code), is that PHP is dynamically typed—variable types are dealt with at runtime rather than at compile time.

Some say that dynamically typed languages are more "dangerous". Passing the wrong type to a function or class method could lead to "disaster". The checks a compiler performs on a statically typed language reduce the number of bugs in an application.

Others, such as Bruce Eckel have a more enlightened point of view. They argue that the tests a compiler performs are really only a subset of unit testing. But that's another story...

PHP5 introduces an interesting new feature called type hinting, which can be used to require that arguments passed to a function or class method are instances of a particular class. For example:

         
<?php          
class Message {          
   private $text = 'This is a message';          
   function getText() {          
       return $this->text;          
   }          
}          
         
class Foo {          
   private $text = 'This is a foo';          
   function getText() {          
       return $this->text;          
   }          
}          
         
class Messenger {          
   private $message;          
   function setMessage(Message $message) {          
       $this->message = $message;          
   }          
   function getMessage() {          
       return $this->message;          
   }          
}          
         
$message = new Message();          
$foo = new Foo();          
         
$messenger = new Messenger();          
$messenger->setMessage($message);          
         
# Fatal error: Argument 1 must be an instance of message          
// $messenger->setMessage($foo);          
         
echo ( $messenger->getMessage()->getText().'<br />' );          
?>          

Script: typehint.php

In the above example, if I try to pass an instance of Foo to the Messenger's setMessage() class, I'll get a fatal error.

When dealing with type hinting, PHP also looks any parent class from which an object descends, so if I made Foo as subclass of Message, I would be allowed to pass it to the setMessage() method of Messenger. This should prove an important feature for developers who want to deliver a really rock-solid API.

Right now, as far as I'm aware, type hinting cannot be used to check for PHP's native, primitive data types (string, int, etc.) and there also doesn't seem to be a mechanism for "type hinting" the value returned from a method or function. Hopefully that's something the PHP group are looking at—it would prove useful in situations when statically typed languages act as a client to a PHP application, such as a Web service.

One particular problem that PHP (and other dynamically typed languages like Perl and Python) has with Web services is the generation of WSDL documents. For languages like Java and C#, a WSDL document can be built automatically by examining the source code for a SOAP service. Today, PHP libraries like PEAR::SOAP have had to define some form of interface definition language, which requires a separate coding effort to make it reflect the real API it’s describing. With full type hinting, it may be possible to generate WSDL automatically from PHP source code, either using some form of introspection, or the tokenizer functions. But I digress...

Namespaces?

Namespaces (and nested classes) are a mechanism common to languages like Java that allow developers to define their own naming scopes, allowing you to declare classes with the same name, for example. These were part of the original plan for PHP5.

Unfortunately, due to implementation issues, they have been dropped for the time being, and are unlikely to return by the time PHP5 reaches a full release.

The reason for this decision is highlighted here. In basic terms, the design that was planned for namespaces in PHP5 turned out to be one which could significantly impact on PHP's performance. Confronted with a choice of stalling the release of PHP5 indefinitely to get this right, or shipping it without namespaces (and adding them at some later date), the team decided on the latter option. My guess is most people would prefer to see PHP5 sooner rather than later.

The common PHP4 workaround for namespaces is to place underscores in the class names, e.g. class UI_HTML_Table{}, which is what we have to keep on doing for the near future.