On one hand I agree, since PHP is so loosely typed. But it's hard to make
the argument that type-hinting return values is pointless, since PHP allows
(class) type-hinting with parameter values. I personally think type-hinting
is very nice, and not for the purposes of IDEs.
The difference is that typehinting works this way:
1. I'm a library, I want to get type X for $foo
2. I put typehint, so I didn't need to check if $foo is X
3. If you pass not X to $foo, my code is going to tell you that you can't do that
And return type works like that:
1. I'm a library writer that says foo() returns X
2. I have to use for it, since I don't use foo()
3. You're client, so you read the docs and see foo() returns X
4. You write code which supposes foo() always returns X
5. I decide these return types are more trouble than they are worth, and make foo() return false on error, removing return type.
6. Your code has no way to check I did that, so it's broken now.
Basically, it sums up to documentation - if documentation isn't right (or if it changed and you didn't follow) your code is going to break and you have no way to prevent it. That's what you have now with @return - why add language construct?
If one of the best selling points of PHP is its typeless environment, then
why make any of these available? It appears that we are moving more and
If it was up to me, I'd probably not bother adding input typehints either :) But as I said above, input typehints are significantly different from return types.
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com