One of the features originally planned for PHP 5.4 was scalar type hinting. But as you know, they weren't included in the release. Recently the topic has come up again on the mailing list and there has been a hell lot of discussion about it. Yesterday ircmaxell published a blog post about his particular proposals. The reactions on reddit were mixed. On one hand it is clear that people do really want scalar type hints, on the other hand they didn't seem to like that particular proposal.

He gets into some of the details of some of the current proposals and their problems like the strict versus loosely-typed nature of PHP and type hinting that was included but not enforced. One he does like, however, is one based on casting - how the variable ends up being cast rather than the specific type it is when it comes into the function/method. This one still has its flaws, so he suggests another method - weak type hints but with stricter input validation (without casting). He also briefly mentions something called "box based type hinting" that would allow users to define their own hinting rules.

Don't worry - code examples (pseudo-code obviously) are included for each of these proposals to help you understand the differences.

In a nutshell, this means that PHP 5.3.99 introduces new syntax -- scalar type hints -- but no new semantics. The latter can either be implemented as an extension written in C/C++, in userland PHP code, or in a tool that statically analyzes the code.

He includes an example fro userland with a "php_check_parameters" function that looks at the arguments of the current method and uses Reflection to check against the type hints for the correct value type.

Some time ago I wrote an article about the implementation of type hints for non-object types for PHP. Meanwhile many things happened and that implementation was replaced by a different one. Readers of my previous post might know that I have doubts about type hints in PHP.

He shows some of the example syntax for the hinting and points out how, in one case, there's no error thrown when the type hint is a native one but an error is thrown on a custom type hint.

So why is there a syntax added which is ignored? [...] Well, I let it to you to decide whether it make sense to have two syntaxes which look the same but do very different things (being ignored vs. throwing a terminating error) and whether it makes sense to push a system where the core language behaves differently depending on the system. [...] I seriously hoped PHP was out of the era of introducing new inconsistencies.

So in my blog series I try to cover all additions to PHP trunk so I have to mention scalar type hints.

He gives examples of both simple hinting (ensuring a value is a float) and a more complex example setting an attribute on a PDO connection (checking for an integer). Sample error messages are included as well. He also gives some advice on mixing strong and weak typing in your apps - it's like "opening a can of worms".

His suggestions include:

• Changing the handling to look for multiples by default
• Avoiding inner looping (repeated looping) and try for code reuse
• Transforming a scalar value into an array to make it easier to handle this way (by casting)
• and how to handle objects in the same array-handling kind of code

He also tosses in a little mention of performance, noting that a call with range in the argument to his array-handling method is faster than looping over the same range and calling the method each time.

About an hour ago, something I've been fighting for almost 2 years happened. The Scalar Type Hinting patch for PHP (the one I wrote almost a year ago) has been adjusted for PHP's trunk tree and committed by Derick.

You can see some of the type hinting features already included in PHP in the manual. This patch adds hinting ability for the other (non-object and non-array) variable types.

On a general level most people agree it would be a good idea to have, since it is an optional feature and does not introduce any regressions, heck you can even mix type hinted code with the non-type hinted one. The "PROBLEM" has always been combining of PHP's typeless nature with type hinting, which is where the consensus has been difficult (impossible) to reach.

He mentions an example of why its such an issue (technically, both 1 and "1" are valid numbers) and includes a link to a patch that gives a new hint to help with the problem.

I admit that these judgments are hard to make. I could be wrong, more or less. Type hints are probably useful when code becomes stable enough and at the boundaries between modules. But I still tend to avoid using them until I get an actual bug that might have been prevented by a type hint. Their usefulness is and has to be an empirical question. The purpose of using them has to be catching errors earlier, so if they don't have that effect, there's no point.

He lists three reasons why he had given up on type hinting before, one being the limited usefulness when it came to objects. Applying it to scalars is a different matter, though, and can prevent improper passing of array/scalars when the other is needed.

Derick himself admits that its probably not the best approach:

The patch is most likely not the best way of implementing this either, and I am also not sure if this patch should be applied to PHP's CVS at all.

He offers the following as an example of how this would be used:

function foo2( integer $i, float $f, bool $b ) { }
foo2( 'string', 42, 49.9 );

The example above should show:

Catchable fatal error: Argument 1 passed to foo2() must be of type integer, string given, called in /tmp/test.php on line 16 and defined in /tmp/test.php on line 12

Derick also posted his Database Design Slides from his talk earlier this year at php|architects php|tek