Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75406
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.207 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <eab1ceea2084415d21736a69c4ac6fdc@mail.gmail.com>
Date: Sun, 13 Jul 2014 15:56:46 +0100
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <9613A07D-D71F-4630-9AA6-5E47677B7281@ajf.me>
References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me> <CAF+90c-ojALBgeyXu+f2tW6LoW8+4XGVpu_+i9SyX=u4RSoxug@mail.gmail.com> <027E65EF-C4FC-474C-92BB-D99EFADDEEED@ajf.me> <ada4093ad61814c182f8ca31939962ea@mail.gmail.com> <BDC11A4E-0610-49A3-B8AE-E9D3627B75C8@ajf.me> <eab1ceea2084415d21736a69c4ac6fdc@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: ajf@ajf.me (Andrea Faulds)


On 13 Jul 2014, at 15:41, Zeev Suraski <zeev@zend.com> wrote:

> I don't think it's a common intentional case, but when writing code
> defensively - you need to be prepared for whatever someone might =
through
> at you...  Say I have a form that accepts 'age', and I expect users to
> type in their age.  As one that develops the backend, it's great if I =
can
> simply stick an 'int' in the function signature that deals with this
> $_GET['age'], and know that whatever the user typed in - it would turn =
it
> to the most sane integer value.  In other words, if someone types in =
'12a'
> (by mistake or intentionally), I think it's a very sane behavior to =
just
> treat it as 12, as opposed to forcing me (the developer) to write =
error
> handling code with a try/catch block, and a fairly hairy try/catch =
block
> too.  Your example of "12 " (that I didn't even think about before) is =
an
> even a more likely scenario, but I think there's no strong reason not =
to
> allow both.

I can see what you=92re getting at, but then I also think allowing =9312a=94=
 and the like could be a source of bugs. In this particular case, I=92d =
probably explicitly cast the age myself before doing anything with it.

Forbidding =9312a=94 is closer to the other type hints, which are =
strict, but is also further away from zpp. I=92m a big conflicted.

For now, I=92ll leave it as E_RECOVERABLE_ERROR. While user input might =
be problematic, it can just be filtered.

--
Andrea Faulds
http://ajf.me/