At 5/11/2004 03:23 PM +0300, Andi Gutmans wrote:
At 11:44 AM 5/11/2004 +0200, Timm Friebe wrote: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 their parameter
> so 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) { // ... } }
class UserClass{ public static function forName($name, $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
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
