Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:31323 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 33602 invoked by uid 1010); 30 Jul 2007 15:38:18 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 33587 invoked from network); 30 Jul 2007 15:38:18 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 30 Jul 2007 15:38:18 -0000 X-Host-Fingerprint: 136.159.238.143 pc143-238.admin.ucalgary.ca Received: from [136.159.238.143] ([136.159.238.143:7193] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B7/75-59109-7E50EA64 for ; Mon, 30 Jul 2007 11:38:16 -0400 Message-ID: To: internals@lists.php.net Date: Mon, 30 Jul 2007 09:38:12 -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> <08.07.20814.2587AA64@pb1.pair.com> <46ABD596.3060005@zend.com> In-Reply-To: <46ABD596.3060005@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) 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. That is true, there is absolutely no reason to say "I'm going to return only type X so I'm making restriction for myself to return only type X". However, this feature is geared towards interfaces, so that statement becomes "Any interface that implements me must provide a method X that takes Y as input and must return Z".