Hi! > On 21 Oct 2014, at 01:32, Stas Malyshev <smalys...@sugarcrm.com> wrote: > > The main problem that happened with scalar typing RFC remains here: > third set of rules for casting types. Of course, since it's "just" > functions and not language constructs, we can have a set of functions > for any set of casting rules anybody wants. But I think it's still the > same problem here - having three sets of casting rules is not good.
We have more than three sets of casting rules, but at least these ones are rather straightforward. > Wait, we actually already have FILTER_VALIDATE_INT and > FILTER_VALIDATE_FLOAT, 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 that would be the fourth set of rules, and the > second set of validation rules, despite already having an extension > specially dedicated to filtering and validation. I think we should not > multiply entities needlessly - if we need some different validation > primitives, why not add them to filter, for example 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 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. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
