Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84156
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error)
Message-ID: <54F42DDF.2070505@lsces.co.uk>
Date: Mon, 02 Mar 2015 09:31:11 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <d238d736f8fcde9e649cb38c9b05fcc1@mail.gmail.com> <DUB113-W139512BB87516EAD168575DF9130@phx.gbl> <ed4e3cf6c363aa74cdd44c7d908f5d3a@mail.gmail.com>
In-Reply-To: <ed4e3cf6c363aa74cdd44c7d908f5d3a@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC
From: lester@lsces.co.uk (Lester Caine)

On 02/03/15 08:39, Zeev Suraski wrote:
>> One scenario I have in mind for this is validating $_GET information for a
>> > RESTful web service. Having potentially an infinite number of URIs that all
>> > point to the same resource isn't good:
>> >
>> > /users/1
>> > /users/%201
>> > /users/1%20
>> > /users/%201%20
>> > /users/%201%20%20
>> > etc.
>> >
>> > In this case, I don't want to accept any leading or trailing spaces for the user
>> > ID. So I would therefore not be able to use an `int` type hint because its
>> > acceptance rules would be too lax.
>> > If spaces are not accepted in stringy ints, and I want to pass a stringy int that
>> > may have leading or trailing spaces in it, then I know I can simply apply a
>> > trim() to it before passing it into a function that's expecting only an int. This
>> > way, the usability of integer-only inputs (as string or ints) isn't compromised
>> > by the rules being too weak.
> Tom,
> 
> First of all thanks for the feedback!  I think that with leading/trailing
> spaces we could go either way.  It boils down to the question of whether
> we want spaces to be explicitly trim()'d and have the rule-set more
> restrictive, or have the rule-set more permissive - preventing some use
> cases from using it and having to do manual validation instead.  Based on
> the fact this has been a source of back & forth changes
> (twitter.com/AndreaFaulds/status/570979956349665281), there's not going to
> be a one size fits all rule-set here.  I think that the use cases where it
> will be harmless to ignore leading/trailing spaces would be more common
> than those where it's risky or undesired...

Andrea's post highlights the fact that we did try a fix when PHP5 came
out. What it fails to add is perhaps why the change was reverted? Still
today there are people pressuring to have it restored? As this thread
has shown. At the end of the day, this fine tuning of casting action has
very little to do with the type hinting debate? Now IS the time to
discuss the rules but not as part of some other RFC? It deserves it's
own independent discussion as it SHOULD apply what ever happens over
type hinting.

Thomas's example in my book is where a number of things come into play?
My first thought would be just where is this actually processed and so
where is it trimmed? Additionally how about '001'? However it does
highlight that a single 'int' hint is not going to satisfy everybody
anyway? The thing perhaps to point out here is that we are looking in
this case at a source that may well be using unicode and wonder if THAT
may not be more of a problem here?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk