Hi,
Just a small addition to what I wrote about handling null ...
function foo(array $d = array()) { var_dump($d); }
foo(null); // This fails with the message: Argument 1 passed to foo()
must be an array, null given
As this code fails I'd not expect to change this behavior for the weak-types.
function foo(int $d = 20) { var_dump($d); }
foo(null); // This should then also fail. Don't care about what's the
default-value.
Bye
Simon
2012/3/8 Simon Schick <simonsimc...@googlemail.com>:
> Hi Arvids,
>
> I pretty much like this idea as it's more strict. Let me say something
> to the questions you pointed out here.
>
> 2012/3/7 Arvids Godjuks <arvids.godj...@gmail.com>:
>> I realize that with scalars it's not that straight forward, but
>> complicating things by adding an auto-cast syntax and so on is just
>> ridiculous. Hints should stay, well, hints. The only problem we have
>> is complications of accepting numerical strings or numbers as strings.
>> And what to do with "null".
>
> I'd like to handle it the same way as it's handled with the classes
> right now. If null is not the default-value you'll get an error when
> you pass null in there.
> One thing I'd like opened here: If you define a default-value
> different than null, should you be able to pass null as well and the
> compiler will use the default-value?
>
>> function a(bool $bool) {}
>> a(10); // Kill your self against the wall - write a(true);
>> If you define bool - use the damn bool!
>
> I like that. What should we do if this appears? As it's now - just
> throw an "Catchable fatal error" and let the script blow-up? I would
> go this far.
>
>>
>> I consider interchangeable only three cases:
>> 1. Numerical string.
>> 2. Integers and floats as strings.
>> 3. Integer and string 0 1 as bool.
>>
>> Any other cases should error out.
>
> Until now I thought about the weak variable-types as a order ...
> string, float, integer, Boolean.
> All Boolean values are compatible be an integer (0 or 1) and all
> integer are compatible to a float and so on. Do you think it's good to
> have it this way? This would mean that you could also get a Boolean
> true as string "1" ... I personally don't like that ... but I don't
> know where to draw the strict-line.
> Now think about that backwards. Can a "1" be passed as a parameter
> that expects Boolean? If yes, I'd keep it consistent in both ways.
>
> Bye
> Simon
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
