Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:31306 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 68632 invoked by uid 1010); 27 Jul 2007 22:57:24 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 68617 invoked from network); 27 Jul 2007 22:57:24 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Jul 2007 22:57:24 -0000 X-Host-Fingerprint: 136.159.238.143 pc143-238.admin.ucalgary.ca Received: from [136.159.238.143] ([136.159.238.143:13739] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 08/07-20814-2587AA64 for ; Fri, 27 Jul 2007 18:57:23 -0400 Message-ID: <08.07.20814.2587AA64@pb1.pair.com> To: internals@lists.php.net Date: Fri, 27 Jul 2007 16:57:19 -0600 User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 References: <74.B1.05050.EADEC964@pb1.pair.com> <98b8086f0707181255q2d338920o741d75b049efb4f7@mail.gmail.com> <469FA4AE.8000905@zend.com> In-Reply-To: <469FA4AE.8000905@zend.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 136.159.238.143 Subject: Re: [PHP-DEV] Re: Type-hinted return values in PHP5? From: david.nqd@gmail.com (David Duong) 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. This feature does not replace good documentation, good testing, or provide any new functionality that could not be recreated by other means. However, it provides a different and often better solution to common problems. Many current PHP projects already have some sort of "module" or "plugin" system how they make use of modules and return type checking (if at all) vary wildly. With THRs future projects would be able to make use of a slightly more advanced language with better support for modular programming. If I, or someone else decided to make a patch for this, and assuming it worked exactly like I described, would it be accepted? Stanislav Malyshev wrote: >> It could be interesting to know, if the reason why this hasn't been >> implemented already, is technical one, or a design decision? > > I think it's design one since nobody took care to design it :) I > personally don't see much need for it, since PHP is not a compiled > language, so there's little use for specific syntax of prescribing value > types. Since PHP has no concept of variable type, it's not clear what > return type hinting would give you that good documenting practices and a > decent IDE won't.