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.
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.
1. It doesn't add new keywords to the language
2. There is no "magic", it would be a runtime error to pass null.
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)
5. It allows optional typed parameters
6. You still have to check for null
7. Downside - you cant pass optional params after the first one.
I patched my code base to see if it would work and it does but it's not an
elegant solution. Basically, inside the vm_handler for ZEND_RECV_INIT, if no
parameter was passed and null has been specified as the default, then it
calls an extended zend_verify_arg_type_ex and passes an allow_null param to
override the IS_NULL check. So now, the code below works as spec'd out
above. Typed optional params that cannot be null.
<?
class Object
{
public function Method(Object $o=null, Object $p=null)
{
if (!is_null($o)) echo 'Got Object'.PHP_EOL;
else echo 'Empty Param'.PHP_EOL;
}
}
$a = new Object();
$a->Method($a);
$a->Method($a, $a);
$a->Method();
$a->Method(null); <-- Error, null not allowed
$a->Method(null, $a); <-- Can't get to second argument since null can not be
passed
?>
#>php -n -f test.php
Got Object
Got Object
Empty Param
Fatal error: Argument 1 must not be null in
E:\php5\php5cvs\php5\Debug_TS\test.php on line 5
Bob Silva
-----Original Message-----
From: Cristiano Duarte [mailto:[EMAIL PROTECTED]
Sent: Saturday, October 16, 2004 4:02 PM
To: [EMAIL PROTECTED]
Subject: RE: [PHP-DEV] Type hints with null default values
Robert Silva wrote:
> PHP doesn't have a concept of a "null" reference though. So to say that
> every other language allows it is not a valid argument. The other
> languages allow it because the language supports it. And that seems to be
> what the arguments against it centered around.
>
> I think a compromise would be to allow the argument to be optional but
> still enforce the type hint. What this doesn't address fully is multiple
> optional type hinted arguments.
>
> function A(ZObj $arg2=null, ZObj $arg3=null) {}
>
> How would you pass $arg3 if you didn't have anything to pass for $arg2.
> Maybe that's just an inherent restriction of the language...to pass $arg3,
> you have to pass a ZObj as $arg2.
Since PHP doesn't support explicit method overloading, we should support
some form of telling the function that $arg2 wasn't passed. This problem can
be solved with named parameters instead os positional ones, but someone
suggested it a long ago and, at that moment, it would not be feasible.
>
> Someone else suggested adding null references to the language:
>
> ZObj $obj = null;
>
> But I don't think that is the right solution either not to mention the
> nightmare of actually implementing it.
It was supported before(until May), isn't it ?
IMHO, what we have now is "not null typehints" so what's the matter if we
accept "not null typehints" when we have this construction:
function A(ZObj $arg2, ZObj $arg3) {}
and "null typehints" with this:
function A(ZObj $arg2=null, ZObj $arg3=null) {}
as we supported before(except that with the first construction nulls are not
allowed). Maybe I'm "blind" but I can't see the problem that Marcus pointed
anymore. If I can remember, he wants a way to enforce typehints not
allowing nulls: construction-1 does it.
I really need optional typehints and construction-2 supports it.
IMHO, everybody would be happy.
Any comments ?
Regards,
Cristiano Duarte
--
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
