FWIW, I don't see much point in this either, as far as error reporting is
concerned. I think type checking for parameters can provide cheap and useful
validation, as parameters passed in are outside the function's control. But return
values? They are within the function's control, and in most functions are not hard
to ensure are correct without needing runtime checking.
If PHP were compiled, not interpreted, i.e. less dynamic, there could be some
benefits, as compile-time optimisations could perhaps be built in, and validations
skipped if they were provably unnecessary. But that's not going to happen any time
soon, as far as I'm aware.
So the only real benefit is that they could make code slightly self-documenting.
But since they would still be optional, they don't help much: the coder might as
well take up the option to write some more useful documentation.
Also, PHP has so many conventions such as returning false on error that don't fit
cleanly into the model, that it's awkward. I'd love to see those problems solved
neatly for function arguments before extending anything to function return types.
I don't think it would do any harm though, so don't see any argument against it. I
just don't think there's a good argument for it.
Ben.
On 28/04/11 6:23 PM, Stas Malyshev wrote:
Hi!
http://wiki.php.net/rfc/returntypehint
for the upcoming 5.4 release, I think it would be extremely useful, even
without the scalar stuff.
Personally, I see even less point in having strict return typing (please stop
using "hint" terminology, it confuses the whole matter, it's not "hint" if it
describes mandatory restriction on the data) than strict argument typing. The
RFC
doesn't explain it either beyond "here how you can have some nice errors".
But why would I want to see these errors? How they would make anything easier or
better?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
