Good points...
Heres another idea which I also implemented and I think others may like it
as well:
Explicitly deny anything except for:
Method(ClassType $a)
And
Method(ClassType $a=false);
Then inside the function itself:
if ($a) $a->DoIt();
Inside the engine, it explicitly checks for the false bool value (this
prevents passing null and unitialized vars as well) then overrides the null
check. Class designers then can be sure that either an object of the
specified class was passed in, or the user wanted to pass no variables at
all. Any other value/var would be an error.
In essence you are changing the way optional params work when paired with a
class hint to say:
When you define a Class Hint on an optional parameter, the default value
represents the only allowed value to be passed in (other than an object of
the proper class).
With that then you can do:
Method(ClassType $a, ClassType $b) {}
$c->Method(false, $b);
The implementation was pretty simple and was much more elegant than the
first method I suggested.
This one I think is workable for the masses.
Forget the other ideas (in retrospect they werent very good) but I think
this one has promise.
Bob
-----Original Message-----
From: Cristiano Duarte [mailto:cunha17@uol.com.br]
Sent: Sunday, October 17, 2004 1:19 PM
To: internals@lists.php.net
Subject: RE: [PHP-DEV] Type hints with null default values
Robert Silva wrote:
> Re-reading the previous discussion, it seems like the functionality that
> people wanted was to have an optional typed argument.
>
> In converting the .NET Framework library over to PHP, there are many
> instances where having optional typed params would have been handy. The
> Framework makes heavy use of interfaces, usually implemented as overloaded
> methods. When implementing it in PHP I had to make use of func_num_args()
> and func_get_args() etc.. to simulate the overloading. As I convert the
> classes over to an extension, I am able to define the method arguments as
> optional and be of a certain type if they are passed. It would be nice to
> have similar functionality in userland.
>
> The quick solution is to have =null override the zend_verify_arg_type
> is_null check, but then this lets users pass null as a value and you lose
> your type hint.
PHP doesn't have (until now) null references, so the only "thing" that we
can handle as a null reference is the type "null"(which isn't a null
reference btw). But I can live with this. :-)
What I propose is something like:
if the typehinted parameter is optional and the user doesn't pass it, the
only "type" it can have (at least now) is "null". So, if you, as a
developer, want a function to have optional typehinted parameters, you must
check for null to test if the user passed the parameter or not, IMHO it's
logical.
function f(Obj $a, Obj $b=null, Obj $c=null) {...}
You can't call f(null) since the first argument is mandatory, typehinted and
doesn't allow nulls, but you can call f(new Obj(), null, new Obj()) since
the second argument is optional and allow nulls(the notation =null).
The only problem with this approach is the fact that we "maybe" want an
optional parameter in which the user can't pass nulls. This is a strange
situation since PHP doesn't allow a notation like:
f(new Obj(),,new Obj())
And we don't have any language construction to pass instead. I really can't
see the point in optional typehinted parameters in which the user can't
pass nulls.
>
> The solution I proposed makes use of the current method of making
> parameters optional, BUT it would still be a runtime error to pass NULL to
> the function.
I really don't need to pass NULL to the function but I need optional
typehinted arguments(not only one, many).
>
> 1. It doesn't add new keywords to the language
+1
> 2. There is no "magic", it would be a runtime error to pass null.
+0
> 3. It does change the "expected" functionality of $obj=default, but it is
> limited to the scope of type hints.
> 4. Doesn't affect BC (since they can't use a default now)
+1
> 5. It allows optional typed parameters
+1
> 6. You still have to check for null
+1
> 7. Downside - you cant pass optional params after the first one.
-1
> (...)Typed optional params that cannot be null.
-1
Regards,
Cristiano Duarte
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
