> On 21 Oct 2014, at 02:08, Stas Malyshev <smalys...@sugarcrm.com> wrote: > >> Actually, to_int is very close to FILTER_VALIDATE_INT, and I’m not >> sure, but I think to_float may be close to FILTER_VALIDATE_FLOAT. The >> main difference with integers is rejection of whitespace and >> toString-able objects. > > So essentially we have a number of rules, which all are only slightly > different. And when somebody wants to skip spaces, but not tabs, we'd > have yet another set of functions?
No, not quite. One of the nice things about rejecting whitespace is it lets you handle it however you want. Want to reject all whitespace? to_int($foo). Want to accept all whitespace? to_int(trim($foo)). Want to trim only tabs? to_int(trim($foo, “\t”)). This is actually allows more flexibility than filter_var does with its maze of flags. > >> The main point of the RFC is to add casting functions as an >> alternative to the built-in explicit casts. Currently, the easiest >> way to convert to an integer is (int), but this is quite dangerous as >> it performs no validation whatsoever and cannot fail. to_int() and > > So, why not have filter_var($suspected_int, FILTER_VALIDATE_INT) and > filter_var($suspected_int, FILTER_CONVERT_INT)? We already have > infrastructure for that, why ignore it completely and build another > solution that does exactly the same but treats whitespace differently > and has couple of other tweaks? OK, you want to treat the whitespace > differently, I get it - but why ignore whole filter infrastructure? It would be possible to make to_int() merely an alias of filter_var(…, FILTER_VALIDATE_INT). Though that would make it depend on ext/filter or otherwise duplicate functionality. Also, treating whitespace differently wasn’t actually my idea. I’m perfectly fine with ignoring it, but Nikita convinced me I shouldn’t tolerate it. He has a point - it opens more possibilities than allowing it. >> the like are intended to be just as convenient as an explicit cast, >> so that doing the safer thing (failing on garbage input) is not any >> more difficult. The hope is that the lazy developer will use is_int() >> instead of (int) when they need to explicitly cast, and avoid the >> problems of the latter. > > The lazy developer won't check the return value anyway and would get 0 > as the result of false-to-int conversion, thus making the whole exercise > pointless anyway :) Not quite. With strict type hints, FALSE would fail for an integer parameter. Even without them, this still makes validation more straightforward. I suppose there are varying degrees of laziness. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
