Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78255
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.182 as permitted sender)
References: <66B7B28C-2651-4A71-AC2A-55D4C7BB3DDC@ajf.me> <CA+9eiLs9j0XMbtNKSSuqTBhF-BEc1CU__3E4gOhYwuF5zF4_1g@mail.gmail.com>
 <866A39C7-6F11-408D-8BCA-594BA22E8569@ajf.me> <CA+9eiLutEFyZsJGu9Qk9C7Jd0P48SBXcdRiVyySbqXbEYm3Y3w@mail.gmail.com>
 <5447682B.2080100@sugarcrm.com> <019325A5-4F82-4179-B4D7-29E5649B2616@ajf.me>
 <54480580.9040302@sugarcrm.com> <4F848DB0-0266-46A0-9805-2B2BF22CAC33@ajf.me>
 <54480F68.6010406@sugarcrm.com> <058059C3-514C-4EA9-9468-3B9A8F20DCA8@ajf.me>
 <54482236.8030408@sugarcrm.com> <A43E2681-954F-4941-8543-FC87D341FE86@ajf.me>
In-Reply-To: <A43E2681-954F-4941-8543-FC87D341FE86@ajf.me>
MIME-Version: 1.0
Thread-Index: AQJkwG276Wk0Upx97kt7WiAQcULrfAGSwBqnAi5QI8QCGl+NrgJ4wNJWAjMdez4Cx9ORzgHpaYzMAtPTfXwCm2dukgGjAcZcAlYyDOSaTf+2cA==
Date: Thu, 23 Oct 2014 01:23:17 +0300
Message-ID: <fdbc5c579b7163b0af4e202db4235306@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>, Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Dmitry Stogov <dmitry@zend.com>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: RE: [PHP-DEV] [RFC] Safe Casting Functions
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: Andrea Faulds [mailto:ajf@ajf.me]
> Sent: Thursday, October 23, 2014 12:42 AM
> To: Stas Malyshev
> Cc: Zeev Suraski; Dmitry Stogov; PHP Internals
> Subject: Re: [PHP-DEV] [RFC] Safe Casting Functions
>
>
> > On 22 Oct 2014, at 22:31, Stas Malyshev <smalyshev@sugarcrm.com>
> wrote:
> >
> > Hi!
> >
> >> Are you opposed to the existence of ext/filter given it has
> >> FILTER_VALIDATE_INT, a =E2=80=9Cprimitive for handling type conversion=
s=E2=80=9D?
> >
> > FILTER_VALIDATE_INT is an option for a filter_var function, and it is
> > not introducing any new rules for handling types in the engine.
>
> Nor is this.
>
> > What you are proposing is not like FILTER_VALIDATE_INT, it's like (int)=
.
>
> I don=E2=80=99t see the difference:
>
>     $x =3D filter_var(FILTER_VALIDATE_INT, $foo);
>
>     $x =3D to_int($foo);
>
> They=E2=80=99re very similar, except the latter has slightly different ru=
les, is
> shorter,
> and if some people (possibly me) get their way, might throw an exception.

Andrea,

You're analyzing this from a purely technical perspective.  There's a world
of difference between these two if we take into account the human element.

The former provides a very clear idea that you're in the context of
filtering and validation.  The whole point of filtering is to, well, filter
out stuff.

The latter, on the other hand, looks like 'PHP, please convert this to an
int for me, the way you do these things, please.'  I know what it does
without looking at the docs.  But actually, I'm wrong - it does something
different, and has a behavior which is fundamentally inconsistent with the
rest of the language that could easily result in broken apps.  to_int()
doing one thing, and (int) doing something completely different?  That's a
major #fail.

If we use more explicit naming, this argument goes away completely.
lossless_int() does a fairly good job at self-describing what it does, and
completely prevents creating the false assumption that it's identical to
PHP's type conversion rules.  The chances the average developer would think
that lossless_int() and (int) are identical is slim to non-existent.

Regarding the fact that it's longer - I think we've made the decision to be
explicit and not try to shorten things up a very long time ago
(unfortunately not long *enough* ago).   Clarity is a heck of a lot more
important than a few extra chars.  Not to mention that in order to properly
use this new mechanism - people will have to write a lot of defensive error
handling code around it - otherwise, what's the point.  People who have a
good reason to use these lossless conversions would not be deterred from 6
extra characters - even at the most minimalistic error handling scenario
we're talking about dozens of extra characters compared to a simple (int)
cast.

Zeev