Hi! > 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.
This looks like "if you don't like my rules, you can easily apply string handling functions to implement any rule you like". Which makes total sense, except if I wanted to play with string handling functions, why not just write a regexp and be done with it? Of course you can do any transformation you like to the data, but if you propose it as a default solution, then "you can add more transformations" is not an advantage - you could always do that. > 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. You seem to sound like depending on something already existing in PHP is a bad thing. > 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 point is not whether ignore or not ignore the whitespace. The point is that having multiple APIs doing the same but differing in one small detail because somebody thinks this detail is not exactly to his liking in existing API - IMO is not a good thing. > Not quite. With strict type hints, FALSE would fail for an integer PHP is not a strictly typed language, so arguing as if it were or just about to become one doesn't sound like a very good selling point. For me, it exactly the reverse - you're emphasizing the fact that for it to work, you need to change the whole nature of PHP not being a strictly typed language. > parameter. Even without them, this still makes validation more > straightforward. I suppose there are varying degrees of laziness. I'm not sure how using function starting with to_ is "more straightforward" than using function starting with filter_ - which seems to be the only thing different here. Except, of course, for whitespace handling. Which in my opinion, still does not explain why we should ignore existing API and create a completely new one. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
