Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78170
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: <5445B206.9010801@sugarcrm.com>
Date: Tue, 21 Oct 2014 02:32:29 +0100
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <D8268C70-4C97-464A-84B4-24466796E842@ajf.me>
References: <66B7B28C-2651-4A71-AC2A-55D4C7BB3DDC@ajf.me> <5445A9AE.2060001@sugarcrm.com> <FD07E554-B2F6-4EBF-81FD-29858B2A6A18@ajf.me> <5445B206.9010801@sugarcrm.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Subject: Re: [PHP-DEV] [RFC] Safe Casting Functions
From: ajf@ajf.me (Andrea Faulds)


> On 21 Oct 2014, at 02:08, Stas Malyshev <smalyshev@sugarcrm.com> =
wrote:
>=20
>> 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.
>=20
> 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, =E2=80=9C\t=E2=80=9D)). This is =
actually allows more flexibility than filter_var does with its maze of =
flags.
>=20
>> 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
>=20
> 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(=E2=80=
=A6, FILTER_VALIDATE_INT). Though that would make it depend on =
ext/filter or otherwise duplicate functionality.

Also, treating whitespace differently wasn=E2=80=99t actually my idea. =
I=E2=80=99m perfectly fine with ignoring it, but Nikita convinced me I =
shouldn=E2=80=99t 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.
>=20
> 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/