At 19:25 22/05/2010, Ilia Alshanetsky wrote:
Zeev,
First of all as far as I can tell majority of the changes relate to
2 new type hints you are suggesting to introduce which are numeric
and scalar. I don't see any issue with adding those two hints,
predominantly for people who don't want to be specific with their
type requirements. So, +1 on that portion of the RFC.
The majority of changes (make sure you look at the latest version as
of about an half an hour ago) is not in terms of what's in there, but
what isn't ('less is more'). The other major change is
auto-conversion when possible, instead of failure.
However, after reviewing your suggested changes to some of the
type-specific hints, I think the changes you are suggesting would
only introduce confusion. There is a substantial WTF factor for
developers, whereby (int)1 === boolean, but (int)12 !== boolean. Or
that (int) 12 is either a valid int or a double, but (double)12 is
only a double.
I think you make a good case, and it wasn't easy to decide how much
(if at all) the auto-conversion rules should be stricter than PHP's
default type conversion rules. I think we can tweak that table. The
only ones I feel strongly about is that we shouldn't accept "abc"
strings as numbers, or arrays/objects as any scalar type. Had we
designed the language from scratch today, we would have probably not
accepted those for auto-conversion either.
For one strict type hints are much clearer, if function/method
expects type X and anything but type X is provided an error is generated.
They may be simpler for you and me to understand, but IMHO not for
the general PHP userbase. Moreover - the fact they may be clearer to
some doesn't necessarily make them more useful. I think
auto-converting type hints are much more useful than strict ones (for
reasons explained in the updated RFC).
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php