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
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
