Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78499
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5452B87B.5040009@garfieldtech.com>
References: <CAL+t6cGt8B+X4ptWbyo6zm_xoyBOJC4QeiH6DjCxHX11CPWm_g@mail.gmail.com>
	<5452B87B.5040009@garfieldtech.com>
Date: Thu, 30 Oct 2014 22:54:05 -0400
Message-ID: <CAL+t6cHqQL-TaurfG887qxeyeVZPCxQcnY_BrtD-oHCS196HQw@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d0442888836889a0506af1cf3
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: theanomaly.is@gmail.com (Sherif Ramadan)

--f46d0442888836889a0506af1cf3
Content-Type: text/plain; charset=UTF-8

So far there seems to be a lot of concern around BC, and particularly
removing or getting rid of GPC superglobals. So I completely understand the
concerns and hope to address them as clearly as possible.

First, for the sake of BC I think removing the superglobals from the
language should not be done here. Instead, for performance reasons, I'm
going to propose that the superglobals are not populated at the request
level. This means that the implementation is free to populate them at will
since they will still exist, but will be initialized to empty arrays by the
language.

Second, it's a valid concern that's there's no actual proposed interface.
So let me be begin by proposing a rough draft for one.

So let's consider the following interface layout and some sample
implementations as a start...

https://gist.github.com/srgoogleguy/f729053e3e88b2d2b3ec

Then let's consider the kind of flexibility this would allow userland in
terms of filtering, validating, and modifying the request data under
various conditions. Obviously, PHP has to provide some form of default
implementation so some base class HttpRequest can be implemented in PHP and
this can be easily extended by userland.

Also, take into consideration the kind of performance gains you might get
out of this by doing things like lazy-loading or lazy parsing or
lazy-filtering of request data. Filters also need not be applied at the
global level. PHP's default implementation would simply use the input
stream to populate GPC as normal (as it currently does), but I believe
introducing the base class will encourage others to make better use of
request/response handling in their own code.

--f46d0442888836889a0506af1cf3--