Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78168
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.75 as permitted sender)
Message-ID: <5445B206.9010801@sugarcrm.com>
Date: Mon, 20 Oct 2014 18:08:22 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: Andrea Faulds <ajf@ajf.me>
CC: PHP Internals <internals@lists.php.net>
References: <66B7B28C-2651-4A71-AC2A-55D4C7BB3DDC@ajf.me> <5445A9AE.2060001@sugarcrm.com> <FD07E554-B2F6-4EBF-81FD-29858B2A6A18@ajf.me>
In-Reply-To: <FD07E554-B2F6-4EBF-81FD-29858B2A6A18@ajf.me>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Safe Casting Functions
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

>> 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 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? I don't think it's good for the
language to have a set of functions doing exactly the same, but in
slightly different way, because some people had different preferences.
The language should not be just a bag of use-cases that somebody wanted
to implement. We're getting a lot of criticism for parts of the language
not always playing cohesively together, why make it worse?

> 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?

> 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 :)
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/