Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:57052
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.49 as permitted sender)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
In-Reply-To: <4EF3C99F.4010300@gmail.com>
Date: Thu, 22 Dec 2011 20:47:58 -0500
Cc: PHP Developers Mailing List <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <3D5E9FD9-74DF-4CF5-B46A-E90ED4E0A152@gmail.com>
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> <4EF3C99F.4010300@gmail.com>
To: =?iso-8859-1?Q?=C1ngel_Gonz=E1lez?= <keisial@gmail.com>
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
From: will.fitch@gmail.com (Will Fitch)


On Dec 22, 2011, at 7:21 PM, =C1ngel Gonz=E1lez wrote:

> On 23/12/11 00:08, Will Fitch wrote:
>> Sent from my iPad
>> On Dec 22, 2011, at 5:51 PM, "=C1ngel Gonz=E1lez" <keisial@gmail.com> =
wrote:
>>=20
>>> 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.
>=20
> 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.

It's not a matter of being difficult.  I can see your argument, however.

>=20
>=20
> For instance, the return hint could go at the end of the prototype:
>=20
> function foo (Class1 $a, Class2 $b) =3D> Class3 {
>   return new Class3($a, $b);
> }
>=20
> (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)

Let me see what can be done without doing too much to the definitions.  =
I like the idea of not making "function" required.

>=20
>=20
>>> In functional programming, it is common to return nullable types:
>>> returns an instance of class Foo or null, an array or false, etc.
>>>=20
>>> 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.
> I disagree with you, but Stas already provided a compelling case.
>=20