Re: Return Type Hinting for Methods RFC
| From: | Will Fitch | Date: | Fri, 23 Dec 2011 01:53:24 +0000 |
| Subject: | Re: Return Type Hinting for Methods RFC | ||
| References: | 1 2 3 4 5 6 7 8 9 10 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-57053@lists.php.net to get a copy of this message | ||
On Dec 22, 2011, at 7:33 PM, Ángel González wrote:
> 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? )
You can return null from methods. Parameters and variables are nullable. I'm not against
appending an indicator as to whether null may be returned, but that would need to be a general
consensus, I think.
I would like other opinions on this...
>
>> 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.
Yes, it would. But providing the option of null would be a good incentive not to do that. At the
end of the day, you're giving a set of tools to someone. If they choose to use it in a way
that's less efficient, or wrong in other's eyes, that's their choice.
>
>