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
