Re: [RFC] Type hints

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


« previous php.internals (#9811) next »