Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:57045
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.170 as permitted sender)
Message-ID: <4EF3C99F.4010300@gmail.com>
Date: Fri, 23 Dec 2011 01:21:51 +0100
User-Agent: Thunderbird
MIME-Version: 1.0
To: Will Fitch <will.fitch@gmail.com>, 
 PHP Developers Mailing List <internals@lists.php.net>
References: <2095305E-D4E3-4D7E-8218-32EE99688E0C@GMAIL.COM> <CAF+90c-Wtok1fnVxokYUFQhbYnMcNDwWWT63F8NDp+JnxCDMew@mail.gmail.com> <2C90FB94-38C4-4270-8C6A-B89304BA8ED8@gmail.com> <CAEZPtU6gneOOehrsz-qVifmNxg6tnyLt9hqfnAwKZmfpXdeC9Q@mail.gmail.com> <159A7CA2-8561-40DA-9434-CAAE12304DDB@gmail.com> <4EF3B56A.4040809@gmail.com> <-2451498990672032588@unknownmsgid>
In-Reply-To: <-2451498990672032588@unknownmsgid>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
From: keisial@gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=)

On 23/12/11 00:08, Will Fitch wrote:
> Sent from my iPad
> On Dec 22, 2011, at 5:51 PM, "Ángel González" <keisial@gmail.com> wrote:
>
>> Your examples only show class methods with visibility qualifyiers, and
>> looking at the changes to zend_language_parser.y
>> it seems as if would only be available for methods. Wouldn't return
>> hints be available for plain functions?
> Right now, it's only available for methods. Personally, I'm not a fan
> of return types for functions. Adding this for functions in its form
> today will also introduce shift/reduce issues.
Yes, it's much easier for the parser for methods with explicit
visibility (note that public is optional).
I'm ok on requiring the public for methods with a return hint, but if
methods can get return hints,
normal functions must, too.

If it's hard with your proposed syntax, it should be discarded and a
better one developed.
Else we would end up with different syntaxes for return hints depending
on the kind of function.


For instance, the return hint could go at the end of the prototype:

function foo (Class1 $a, Class2 $b) => Class3 {
   return new Class3($a, $b);
}

(I'm unsure about the T_DOUBLE_ARROW, although for parsing, I feel there
should be some token there
before the class name, though I'm unconvinced on which)


>> In functional programming, it is common to return nullable types:
>> returns an instance of class Foo or null, an array or false, etc.
>>
>> This is supported in normal arguments with the "= null" hint, and I
>> think there should be something equivalent for return types.
>> Does the proposed implementation allow null everywhere? (there's an
>> example of returning null from a return hint of array)
>> That seems wrong to me. Unless there's a way to make it strict (eg.
>> array! for only arrays).
> Most modern languages allow returning null in any case. This is a hail
> Mary in the event something happens, but throwing an exception is
> inappropriate. I see no reason to diverge from that.
I disagree with you, but Stas already provided a compelling case.