Re: [RFC] Type hints
| From: | Jason Garber | Date: | Tue, 11 May 2004 12:36:42 +0000 |
| Subject: | Re: [RFC] Type hints | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-9811@lists.php.net to get a copy of this message | ||
Consider this below:
At 5/11/2004 03:23 PM +0300, Andi Gutmans wrote:
At 11:44 AM 5/11/2004 +0200, Timm Friebe wrote:class UserClass{ public static function forName($name, $c = NULL) {On Mon, 2004-05-10 at 18:16, Andi Gutmans wrote:I think it's hard to put closure on this type hints issue.[...]As no good syntax has been found for the less common case of allowing NULL's, I think the best solution for now is not to allow null in the regular type hint syntax, and have people who want to allow NULL's not use type hints at all (in any case, they need to manually check theirparameterso they'll do one more manual check).Will this affect optional arguments? I.e., will the following still work? class UserClass {public static function forName($name, ClassLoader $c= NULL) { // ... }}
if(is_null($c))
//...
elseif($c instanceof ClassLoader)
//...
else
//Throw an error
}
}
Using this method, you can easily solve the issue pointed out above, while allowing the type hint to be strict.
~Jason
$works= UserClass::forName('MySQLConnection'); (not passing any value for the optional parameter) vs. $fails= UserClass::forName('MySQLConnection', NULL); (passing NULL as "value" for the optional parameter)Nope, why would it work? If we make the type hint strict (which I think we should) then you can't define it to NULL. Doing so would be kind of inconsistent. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php