Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:57046
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
Message-ID: <4EF3CC69.3000103@gmail.com>
Date: Fri, 23 Dec 2011 01:33:45 +0100
User-Agent: Thunderbird
MIME-Version: 1.0
To: Will Fitch <will.fitch@gmail.com>
CC: Stas Malyshev <smalyshev@sugarcrm.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> <4EF3BD21.2040301@sugarcrm.com> <-6952580475866195972@unknownmsgid>
In-Reply-To: <-6952580475866195972@unknownmsgid>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
From: keisial@gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=)

On 23/12/11 01:00, Will Fitch wrote:
> On Dec 22, 2011, at 6:28 PM, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
>> In PHP, returning object if everything is OK and false if not is a very common pattern.
>> Also, you understand that always allowing null means that this construct:
>>
>> $foo = $this->returnsFoo();
>> $foo->fooMethod();
>>
>> is no longer safe as you wanted it to be when you made returnsFoo use strict typing? You'd have to check $foo anyway.
> Are you suggesting not allowing null to be returned, or provide an
> indicator within the syntax that it may return null? 
It should be possible to allow it. Either with a generic syntax for
allowing
many types of return types or through a specific one (eg. in C# a ?
marks an internal type as nullable: int? )

>  PHP would be the
> first language I'm aware of that would do so in either case.
It already barfs at you if you pass null to a parameter expecting a
given class
(though you can allow it).


> The point isn't to restrict a type hint to always be returned. The
> goal is to guarantee that if a value is returned, it will be of type
> X. In the event it is inappropriate to return the value back, would
> you rather receive null or a bogus class instance, empty array or a
> random function name back? Because that's what will happen. It will
> become the "workaround" for not being able to return null.
As it would support both ways, it's up to the framework to choose if
they want to
return null or a fake-class interface.