Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:57950
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.170 as permitted sender)
Received-SPF: pass (google.com: domain of dmgx.michael@gmail.com designates 10.216.134.157 as permitted sender) client-ip=10.216.134.157;
MIME-Version: 1.0
In-Reply-To: <8D8E9A0839FE464FBBDF2B499DAFA596@gmail.com>
References: <CAGovj_PbjoB78kXvZcaSkx3qQziMXX7ezVmzYSPHQbJL7uu7VA@mail.gmail.com>
	<8D8E9A0839FE464FBBDF2B499DAFA596@gmail.com>
Date: Wed, 22 Feb 2012 10:10:38 -0500
Message-ID: <CAGovj_OA29qv0MvpFwaT6EF4h_+CYuirNY8nLBaqGurkdO3Afw@mail.gmail.com>
To: PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] $_PARAMETERS Super Global Object
From: dmgx.michael@gmail.com (Michael Morris)

$_REQUEST does nothing of the sort, and it's use is dangerous in
RESTful architecture.  $_REQUEST is a smash together of $_GET, $_POST
and $_COOKIE, in that order but the php.ini directive can change it.
Hence there's no way of knowing if $_REQUEST['password'] came from
$_COOKIE, $_POST, or $_GET, and worse, if two values in those source
arrays have the same key $_REQUEST will overwrite them.  $_REQUEST to
be honest, is a lame shortcut and bad idea almost on par with
register_globals.

I'm not recommending $_REQUEST.

$_PARAMETERS is an object, not an array.  I suppose if treated like an
array it could behave like request - but I deeply dislike that idea
because it is a repeat of the mistake of $_REQUEST.

To get a value from a get request I'd use $_PARAMETERS->get['myVar'];
To get it's filtered value I'd use $_PARAMETERS->get->filtered['myVar']
To set those filters I'd use $_PARAMETERS->get->setFilters( $filters );



On Wed, Feb 22, 2012 at 10:03 AM, Will Fitch <will.fitch@gmail.com> wrote:
> Personally, I don't like this. =A0We already have $_REQUEST which can
> accommodate GET, POST, and COOKIE. I believe it should be up to
> framework/API authors to implement there own methodologies behind accessi=
ng
> this data. =A0Additional functionality such as setting filters would be a=
 part
> of that as well.
>
> That said, if you're serious about the idea, a RFC would be helpful in
> understanding the full extent that you're suggesting.
>
> --
> Will Fitch
>
> On Wednesday, February 22, 2012 at 9:57 AM, Michael Morris wrote:
>
> Before writing up a full RFC I want to put out a feeler on something.
> Currently we have several input parameter objects, chief among them
> $_GET, $_POST, $_REQUEST, $_SERVER (for the client HTTP headers). All
> of them are arrays and legacy code sometimes writes to them. Locking
> them as read only objects would cause a major BC break.
>
> What if instead we had an Object called $_PARAMETERS which holds the
> read only copies of this data. In addition, this would be the first
> superglobal object, able to perform some filtering of inputs. Basic
> idea..
>
> $_PARAMETERS
> ->get
> ->post
> ->cookie
> ->headers (The client http headers)
>
> All of these would be array objects, and all would be read only and
> have these methods and properties
>
> ->filtered: Copy of the array according to the current set filters of
> the object.
> ->setFilters(): Sets the filters of the input, an array with constant
> values for the allowed types.
>
> And I'll stop there. The basic idea, to add a read only input hive
> with some basic object functionality for filtering.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>