Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78166
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 198.187.29.244 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
In-Reply-To: <5445A9AE.2060001@sugarcrm.com>
Date: Tue, 21 Oct 2014 01:49:07 +0100
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <FD07E554-B2F6-4EBF-81FD-29858B2A6A18@ajf.me>
References: <66B7B28C-2651-4A71-AC2A-55D4C7BB3DDC@ajf.me> <5445A9AE.2060001@sugarcrm.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Subject: Re: [PHP-DEV] [RFC] Safe Casting Functions
From: ajf@ajf.me (Andrea Faulds)

Hi!

> On 21 Oct 2014, at 01:32, Stas Malyshev <smalyshev@sugarcrm.com> =
wrote:
>=20
> 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=E2=80=99m =
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/