On Mon, May 24, 2010 at 1:48 PM, <s...@geleia.net> wrote: > I think the best option is to align the type checking with > zend_parse_parameters (this is not the same as an implicit cast) and make > it stricter. This includes: > * disallow string to float/int when it contains non-numeric characters > (includes "123abc") > * disallow string/float to int when it causes overflow instead of the > current behavior (triple cast (long)(unsigned long)(long long)). "L" would > retain the current behavior. > > Although a depart from backwards compatibility, I doubt this would cause > much brekage.
If you're suggesting to change the default behavior of type casts, I think this would be a fairly big BC issue. I know I've (ab)used and have seen it used as well by others the fact that (int)"123abc" gives you 123, for example parsing urls that have id-some-name, you just cast it to int and you've got the id. I would welcome such change in the next major release, but you have to realize it will break stuff. As for the specific issue of type hints, I'd vote for 3rd approach, too strict (1) will be a nightmare given PHP's flexible nature, and current rules (2) are really too permissive so if you use that you basically still have to validate everything, not much benefit from adding type hints. Basically if the conversion is loss-less, it should be allowed, otherwise the API user should validate beforehand. Cheers -- Jordi Boggiano @seldaek :: http://seld.be/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
