If so, maybe allow the type hint to always succeed, if it's got NULL as the
default parameter?
(that way foo() wouldn't act differently to foo(NULL), even though they both
mean the same thing, ignoring the type hint)
Jevon
----- Original Message -----
From: "Timm Friebe" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, May 11, 2004 9:44 PM
Subject: Re: [PHP-DEV] [RFC] Type hints
> 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) {
> // ...
> }
> }
>
> $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)
>
> - Timm
>
> --
> 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
