Re: Return Type Hinting for Methods RFC

From: 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.

« previous php.internals (#57046) next »