Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52062
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=c01DsfLo8arSMEuDWLuHnmVB2p3j8DEYkOXqFBwcEUReWEOsxb4zIFEFqNaEf1bWM1
         QZOfF/ljbt7sYk7JuHGATKBq0oVTsFBbgDS4ZXFVqCfMbNR5PWj5YCAsCuL18BPH3iXi
         6Ck0rEgJyvIuAzGiyVaS04wNpyVTUWmiW4Eds=
MIME-Version: 1.0
In-Reply-To: <4DB98E8A.409@yahoo.com.au>
References: <AANLkTimDdM4Udx53qW8jU4NuP3kU8+vmU6y4ZgXRVn+X@mail.gmail.com>
	<BANLkTinMW_iqqOPJCuLnCB+-VEKxapPdGg@mail.gmail.com>
	<4DB923E6.3020307@sugarcrm.com>
	<4DB98E8A.409@yahoo.com.au>
Date: Thu, 28 Apr 2011 14:22:42 -0300
Message-ID: <BANLkTi=esxE_pjpu9eXKpFm1-M7kxoaSdg@mail.gmail.com>
To: Ben Schmidt <mail_ben_schmidt@yahoo.com.au>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=0016e6471c780d50ef04a1fdceac
Subject: Re: [PHP-DEV] [RFC] Return type-hint
From: martinscotta@gmail.com (Martin Scotta)

--0016e6471c780d50ef04a1fdceac
Content-Type: text/plain; charset=ISO-8859-1

 Martin Scotta


On Thu, Apr 28, 2011 at 12:58 PM, Ben Schmidt <mail_ben_schmidt@yahoo.com.au
> wrote:

> 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.
>

Yes, PHP is interpreted, but remember that PHP has its own "compile-time".
An option could be to use the "hints" only for compile purposes, but then at
runtime the core can behave as it's today.


>
> 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?
>>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--0016e6471c780d50ef04a1fdceac--