Sherif, I have to disagree with you on this in the same way that we have type hints for input variables on methods, this could also be useful. Consider an interface with a getter method defined. As it stands now in php, they're not entirely useful, since you can't define what type of object your expecting from the implementer. That greatly reduces the functionality of an interface and this proposal gives solution to that problem.
Florin, I think the overall concept is good, I want to see something like this in the future, but I think this might be the wrong approach. I don't think we should be hinting primitives. if we're going to have a return type hint on a method, I would have it match the functionality of the input type hints for functions we already have, where you can hint at an instance of an object type, such as Iterator or StdClass, or an array, but not hint primitives such as int and string, like I currently see in the draft. Also, you should be aware that your proposed syntax for the return type ( <type> ) is interfering with: https://wiki.php.net/rfc/protocol_type_hintingand seems unnecessary to me. On Wed, Jun 26, 2013 at 5:08 AM, Sherif Ramadan <theanomaly...@gmail.com>wrote: > On Wed, Jun 26, 2013 at 5:50 AM, Florin Patan <florinpa...@gmail.com> > wrote: > > > Hello PHP internals, > > > > > > Currently PHP doesn't support what could be a good feature for code > > quality, return typing (or if you prefer to call it: return type > > hinting). > > > > Since the procedure says that before any real RFC should be done, the > > interest for this topic should be gauged, I've drafted something here: > > https://gist.github.com/dlsniper/5863012 > > > > The goals for this discussion are: > > - gauge the interest in having such a feature in PHP.NEXT > > - find weak spots in the draft > > - find potential problems with the suggested way of doing the > > implementation > > - determine if the advantages would outweigh the disadvantages and > > this should go forward as a RFC > > > > As you can see, the draft doesn't include any patch and since my C > > skills are mostly nonexistent, I currently can't provide one > > unfortunately. I would however love to do it with proper guidance from > > someone that could spare some of his/her time to help me out. > > > > This said, thank you very much for your time, consideration and > > feedback on this subject. > > > > > > Best regards, > > Florin > > ---- > > Florin Patan > > https://github.com/dlsniper > > http://www.linkedin.com/in/florinpatan > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > PHP really doesn't need function return type declaration since PHP doesn't > even support variable declaration. This would make sense in a language like > C or C++ where the compiler can do static analyses to determine potential > errors before compiling. > > Since PHP is a loosely typed dynamic language, however, the fact that a > function can return something of any type is quite liberating and it turns > out that you don't need the static analyses to write better code with PHP, > because most of the errors static analyses helps you with aren't really the > things you are most concerned with. For example consider the following bug: > > <?php > function userTimezone($userId, PDO $db) { > $result = []; > if (!($stmt = $db->prepare('SELECT `timezone` FROM users WHERE > users.`id` = ?'))) { > return false; > } > if ($stmt->execute([$userId])) { > $result = $stmt->fetchAll(PDO::FETCH_ASSOC); > } > return array_pop($result); > } > ?> > > If in the above code PDO::prepare returns false (upon failure) for any > reason $stmt will not be of the expected type. In that case the function > returns a boolean false to indicate failure (or it can throw an exception > as well). If the Exception is throw the function's return value is still > implicitly null. However, the return type of the function isn't what we > actually care about here, because it doesn't solve our real problem. The > real problem we care about is the fact that the function failed and > couldn't keep its promise. If we force the function to only return an array > we can't tell the difference between an empty result set or a failure case > unless we strictly stick to exceptions. In none of those cases was the > function's return value type hint helpful. >
