26

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?

Improve this question

6 Answers 6

Reset to default
38

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 can't specify type hinting for bool, int, string, float, which makes sense in a dynamic context.)

Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

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.
I dunno, PHP is growing (OOP). Strict interfaces for complex data types makes sense to me.
Besides, you get the best of both worlds, define strictness where it matters, or not, and leave the small stuff dynamic.
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.
18

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.

Improve this answer

3 Comments

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?
In that case, create an interface for your object, which would implement it, and type hint your function with that interface name. Solid contract.
True. Always (Well perhaps save a few cases) typehint to interfaces - not concrete classes.
13

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.

Improve this answer

Comments

6

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.

Improve this answer

Comments

0

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

Improve this answer

1 Comment

There's phpdoc annotation for that
-4

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.

Improve this answer

1 Comment

Follow this advice if you want to litter your code and your life with exception handling and trivial, redundant unit tests that can be replaced with an off-the-shelf IDE and static analyzer that would do the work for you. Ah, and another motivation to follow this advice is to trash the readability, maintainability, and refactorability of your code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.