Hey Zeev, > Another change being considered and not yet in the RFC is re-allowing > leading and trailing spaces for numeric strings (sorry Paddy.)
I think that rejecting leading and trailing spaces for stringy ints is for the best. If I only want to accept an integer (in either int or string form), then by enabling spaces in that input, it would destroy the overall usability of it. One scenario I have in mind for this is validating $_GET information for a RESTful web service. Having potentially an infinite number of URIs that all point to the same resource isn't good: /users/1 /users/%201 /users/1%20 /users/%201%20 /users/%201%20%20 etc. In this case, I don't want to accept any leading or trailing spaces for the user ID. So I would therefore not be able to use an `int` type hint because its acceptance rules would be too lax. If spaces are not accepted in stringy ints, and I want to pass a stringy int that may have leading or trailing spaces in it, then I know I can simply apply a trim() to it before passing it into a function that's expecting only an int. This way, the usability of integer-only inputs (as string or ints) isn't compromised by the rules being too weak. > The takeaway from this seems to be that the approach of tightening the > existing rule-set and applying it to both internal functions and new > user-land code is viable, and does not cause the sky to come down falling. > Preliminary tests suggest it actually finds real potential problems. > > More tomorrow. Overall, a big +1 on this though! The type coercion rules at the moment are far too lax to be considered useful in most situations IMO. > Zeev Thanks, Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
