It would give you similar benefits to input type hinting, but instead of "Functions are now able to force parameters to be objects...", it would also read "Calling functions are now able to expect return types to be objects...". If a function was defined to return object Z, but instead returned false, then obviously there is something wrong and it could be caught before calling code sees it expecting it to be something else.
Catching language-level error in application code is usually harder than just handling it in user code. And if you are talking about distinction between false/null and actual object, language level is the wrong level to catch such things. If you handle the error in runtime, you could have the check as well. If you don't, the script breaks anyway, so it is not going to help you much. Even more, the return value is the product of the module code, while input values are product of the outside code. So when you say "I'm going to process only type X, and I make a requirement for others to pass only X to me", it makes for me more sense than saying "I'm going to return only type X so I'm making restriction for myself to return only type X". The latter is more like declaring variable types, which have its functions in compiled languages but usually is not happening in dynamic interpreted languages. Also, since from the client side there's no way to check if the function you are calling actually does have the return type restriction, it's quite hard to program basing on that from the client side. So you actually check it in one place (library) and use it in entirely different place (client) which is usually bad idea since the client becomes too reliant on internal details of the library.
If I, or someone else decided to make a patch for this, and assuming it worked exactly like I described, would it be accepted?
I don't know... I personally don't see much use for it, but others may disagree.
-- 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
