Type hinting allows you to tell a function which data type to accept for its arguments. When you call a function, if a type hint is present, the argument passed will be checked to make sure it is of the type specified. If a function has control over what it accepts as an argument, then it is more likely that the code within the function will have the data it needs to perform the task it is intended for.

He includes two code examples - one not using a type hinting on the parameters (assuming the correct arguments) and another forcing the input of the "PrintGuitar" method to be a "Guitar" object instance. You can find out more about type hinting in the PHP manual.

Design by contract is an important concept for controlling what type of input your methods or functions can receive. One of the most dangerous features of PHP is that functions will still execute even when they are missing required arguments, by emitting a warning instead of an error. In this post, I am going to walk through some of the solutions available to deal with this problem.

He shows how to alter a basic function to first use type hinting to catch when a variable is the wrong type (in this case checking for an array and stdClass) which causes a Fatal error and makes the function not execute. He includes sample code for the type/value checking option and also includes a suggestion of using PHPUnit's assertions as another option.

Finally, he introduces the ContractLib tool (from Stuart Herbert) that makes use of closures to enforce checks - his example checks to see if something is a string and that it's not empty.

I like PHP closures and their superset, anomyous functions, as they implement the Command pattern very well when used correctly. However I feel that sometimes they are: difficult to reuse and difficult to force contracts on. [...] What if we wanted instead, a closure which we can instance even more than one time (maybe with different variables), and that we could type hint?

He shows how to make this possible with a functor created using the __invoke magic method of PHP to handle the request to an object like a function. He includes some sample code to show it in action - a basic callback (SquareCallback) and how it compares to calling a normal closure. It also shows something a bit more technical, an "AdderCallback" class that can be defined as a type hint on a function.

Every class has an interface, every class can be typehinted as a method argument, typehint lets you specify the collaborator requirements. Not every typehint is the same.

He includes an example of how, despite a "BankAccount" type hint, classes for different types of accounts can be created and methods from the parent can be overwritten. To help remedy the situation, he shows a more structured example that uses interfaces/an abstract class to define the BankAccount structure, setting requirements on the child class functionality.

Unfortunately, while initial outpouring of support for inclusion of type hinting into PHP 5.3 and 6 was substantial, it all kinda petered out once more people started voting. To be specific, there is a large amount of support for the feature in general, but very few people seem to think it should go into 5.3. [...] That said, at work we will transition to 5.3 soon, probably around 5.3.2/3 time, so I do need a type hinting patch. To that effect I've cleaned up and improved the old patch based on comments from various people, notably Stas and Dmitry (thank guys) and made a copy that I intend to use for work.

He talks about how the patch works - no more virtual types and no casting support. Three things have been changed to make it all work: modification to the parser, added a getTypeHint function, properly parse type hints in the code.

I'm currently working on [a project] where I've been experimenting with 'domain objects' having 'scalar' or 'value' objects as properties (more on that later).

The talks specifically about two of the upcoming features - type hinting and the __cast magic method that allows you to correctly cast a variable into a different type. He illustrates with some code that handles and manipulates user data and handles exceptions on an incorrect type cast.

It is now compatible with the current version of PHP 5.3 (right now it is RC2). I think we won't see any major changes with the namespace handling in PHP 5.3 anymore, so I felt I could upgrade the library.

You can clone the source for the tool from its github page and check out the blog post for an example of it in use.

• In this new post, Frank Kleine takes things a step further and talks about the same kind of type hinting but for more types - including arrays and objects. Examples of how he'd expect things to work followed.
• The other post is from Stephan Schmidt again and varies slightly off into the world of Namespaces to be included in PHP6 along with the use of annotations.

I was very pleased, that PHP 5 introduced type hints, although they are not available for primitives like string, int, boolean, etc. Still, I'd like to see the object type hint introduced in any future version of PHP that allows me to specify, that a method or function only accepts an object, regardless of the type of the object.

He gives the example of Java's handling of the functionality and what PHP does with the same type of code. He also mentions that, via the Reflection API extension, some of this is possible already, so why not just include it from here on out?