Re: Return Type Hinting for Methods RFC
| From: | Ángel González | Date: | Fri, 23 Dec 2011 00:33:45 +0000 |
| Subject: | Re: Return Type Hinting for Methods RFC | ||
| References: | 1 2 3 4 5 6 7 8 9 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-57046@lists.php.net to get a copy of this message | ||
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.