Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52058
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain yahoo.com.au from 98.139.91.96 cause and error)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com.au;
  h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding;
  b=nTMnVOXmPK+aznrrsL7v4j6SgJQiWhFYOvKYpMWAhu1yK1JMwbgmBvrJmyWrjSPijBjjW9X6jb+wgNX1XjaXus0DFDHL/A1pnO/ZXQEiiO2Dce1TvA0APkw65v3rzRQobTBKgU6BLyu9sfhZAOC2UxZaIady+5/T/F8aU8CJWX4=  ;
Message-ID: <4DB98E8A.409@yahoo.com.au>
Date: Fri, 29 Apr 2011 01:58:02 +1000
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 ThunderBrowse/3.3.5
MIME-Version: 1.0
To: internals@lists.php.net
References: <AANLkTimDdM4Udx53qW8jU4NuP3kU8+vmU6y4ZgXRVn+X@mail.gmail.com> <BANLkTinMW_iqqOPJCuLnCB+-VEKxapPdGg@mail.gmail.com> <4DB923E6.3020307@sugarcrm.com>
In-Reply-To: <4DB923E6.3020307@sugarcrm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Return type-hint
From: mail_ben_schmidt@yahoo.com.au (Ben Schmidt)

FWIW, I don't see much point in this either, as far as error reporting is 
concerned. I think type checking for parameters can provide cheap and useful 
validation, as parameters passed in are outside the function's control. But return 
values? They are within the function's control, and in most functions are not hard 
to ensure are correct without needing runtime checking.

If PHP were compiled, not interpreted, i.e. less dynamic, there could be some 
benefits, as compile-time optimisations could perhaps be built in, and validations 
skipped if they were provably unnecessary. But that's not going to happen any time 
soon, as far as I'm aware.

So the only real benefit is that they could make code slightly self-documenting. 
But since they would still be optional, they don't help much: the coder might as 
well take up the option to write some more useful documentation.

Also, PHP has so many conventions such as returning false on error that don't fit 
cleanly into the model, that it's awkward. I'd love to see those problems solved 
neatly for function arguments before extending anything to function return types.

I don't think it would do any harm though, so don't see any argument against it. I 
just don't think there's a good argument for it.

Ben.



On 28/04/11 6:23 PM, Stas Malyshev wrote:
> Hi!
>
>>> http://wiki.php.net/rfc/returntypehint
>> for the upcoming 5.4 release, I think it would be extremely useful, even
>> without the scalar stuff.
>
>
> Personally, I see even less point in having strict return typing (please stop
> using "hint" terminology, it confuses the whole matter, it's not "hint" if it
> describes mandatory restriction on the data) than strict argument typing. The RFC
> doesn't explain it either beyond "here how you can have some nice errors".
> But why would I want to see these errors? How they would make anything easier or
> better?