Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:57038
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.170 as permitted sender)
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>
In-Reply-To: <4EF3B56A.4040809@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Thu, 22 Dec 2011 18:08:26 -0500
Message-ID: <-2451498990672032588@unknownmsgid>
To: =?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?= <keisial@gmail.com>
Cc: PHP Developers Mailing List <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
From: will.fitch@gmail.com (Will Fitch)

Sent from my iPad
On Dec 22, 2011, at 5:51 PM, "=C3=81ngel Gonz=C3=A1lez" <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.

>
> 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 "=3D 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.

>