views:

721

answers:

5

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 everywhere. Now I think it's a bad idea, as far as duck typing assures minimal coupling between the classes, and leverages the code modularization and reuse.

It feels like type hints split the language into 2 dialects: some people write the code in static-language style, with the hints, and others stick to the good old dynamic language model. Or is it not "all or nothing" situation? Should I somehow mix those two styles, when appropriate?

+9  A: 

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.

soulmerge
Well, my code in PHP relies only on the presence of the methods that I call against a passed parameter object. Why constrain myself with demanding a certain type?
Ivan Krechetov
In that case, create an interface for your object, which would implement it, and type hint your function with that interface name. Solid contract.
Mario
True. Always (Well perhaps save a few cases) typehint to interfaces - not concrete classes.
troelskn
+10  A: 

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.)

Mario
Right, I agree. I just feel that all that strict contracts are somehow alien to the initially duck-typed language. PHP is already ugly enough, and type hinting makes it look even more like a heap of unrelated features.
Ivan Krechetov
I dunno, PHP is growing (OOP). Strict interfaces for complex data types makes sense to me.
Mario
Besides, you get the best of both worlds, define strictness where it matters, or not, and leave the small stuff dynamic.
Mario
There comes eventually a point where you have to check if the stuff you get in is really the type of thing you are expecting. Typehinting allows to do that right in the function definition.
Ikke
A: 

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).

Morten Christiansen
There's phpdoc annotation for that
Ivan Krechetov
+1  A: 

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.

Ionuț G. Stan
+3  A: 

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.

Alan Storm