And Zend Studio does this for you already, if you use comment your code correctly. I really don't see a good use for this, either.
Jeremy -----Original Message----- From: Larry Garfield [mailto:[EMAIL PROTECTED] Sent: Saturday, July 28, 2007 6:05 PM To: internals@lists.php.net Subject: Re: [PHP-DEV] Re: Type-hinted return values in PHP5? On Saturday 28 July 2007, Stanislav Malyshev wrote: > > 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. I think the only serious advantage I could see would be to allow context-assistance IDEs more data, so they could provide method-completion. As nice a feature as that would be, I don't think it's worth modifying the language syntax for. I agree that in a loosely typed language that sort of thing needs to be checked by the application code anyway. -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
