(When) should I use type hinting in PHP?

Question

I can\'t understand the motivation of PHP authors to add the type hinting. I happily lived before it appeared. Then, as it was added to PHP 5, I started specifying types eve

Answer 1

Type hinting is a point of debate at our company (mostly the Java people like it), and I am a very old school PHP programmer (and program in other languages).

My advice is to avoid type hinting and to include try/catch handlers in each complex function.

Type hinting forces an application to rely on the callers exception handling environment which is in general bad and goes untested, the primary problem. For web apps, this results in the white screen of death, for batch it results in simply a fatal exit without logging good messages in most cases, and you sitting their scratching your head trying to recreate the user or application problem that management is on your back to resolve.

Local exception handling provides for a more controlled testing scenario including garbage in data types and garbage in data values, which gives a much more complete testing suite compared to a difficult to test exception handling path in the caller by passing in an incorrect type and expecting the exception.

The exception testing also fails in many cases due to stack version problems (i.e. some versions of PHP like 5.4 do not catch "catchable fatal" errors in a proper way and ergo phpunit simply dies breaking testing suites. This is a stack specific problem, however in my experience type hinting simply is unnecessary, makes people that are used to a typed language accept PHP better without realizing the impact, and causes much more complex testing scenarios (very difficult to test the callers handling exception path results).

The Java and other typed language folks are not accepting of or understanding how to leverage and benefit from the default mixed type parameters in PHP... They will learn someday but only if they embrace the PHP way. ;-)

Best lessons are learned when developing robust PHP unit based testing scenarios, and that will normally shed light on why type hinting is a pain in the butt related to testing, and causes much more problem than good... To each their own, and my apps run better and more reliably and testing turn out much more complete with generally 100% code coverage including catch paths in local functions.

Answer 2

The motivation of the PHP group to add type hinting was to provide people used to Java-style OOP with another feature that would make the platform more familiar, comfortable, and appealing. This, in turn, would make PHP more "enterprise ready", which would help Zend with their core business.

Marketing aside, it does have its uses. If you're writing a method that operates on a parameter in a specific way that would cause unintended (often silent) failures if the parameter was something else, then using type hinting ensures the code will break during development rather than breaking in production.

Answer 3

You should use type hinting whenever the code in your function definitely relies on the type of the passed parameter. The code would generate an error anyway, but the type hint will give you a better error message.

Answer 4

If you ever decide doing type hinting at least do it using interfaces instead of concrete or abstract classes. The reason is simple, PHP does not allow multiple inheritance but does allow implementing multiple interfaces. So if anyone tries to use your library it won't have difficulties implementing your interface as opposed to the case where he would have to extend your abstract/concrete class given that he already extends another already.

Answer 5

Without type hinting it would be impossible for the IDE to know the type of a method parameter and thus provide the proper intellisense - your editor does have intellisense, right? ;). It should be said that I just assume IDEs use this for intellisense, as this is the first I've heard of type hinting in PHP (thanks for the hint btw).

Answer 6

It's not about static vs dynamic typing, php is still dynamic. It's about contracts for interfaces. If you know a function requires an array as one of its parameters, force it right there in the function definition. I prefer to fail fast, rather than erroring later down in the function.

(Also note that you cant specify type hinting for bool, int, string, float, which makes sense in a dynamic context.)