Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78503
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 198.187.29.244 as permitted sender)
References: <CAL+t6cGt8B+X4ptWbyo6zm_xoyBOJC4QeiH6DjCxHX11CPWm_g@mail.gmail.com> <5452B87B.5040009@garfieldtech.com> <CAL+t6cHqQL-TaurfG887qxeyeVZPCxQcnY_BrtD-oHCS196HQw@mail.gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <CAL+t6cHqQL-TaurfG887qxeyeVZPCxQcnY_BrtD-oHCS196HQw@mail.gmail.com>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-ID: <0B797CE3-7AFA-4330-9A98-D3CAFC6D6072@ajf.me>
Cc: Larry Garfield <larry@garfieldtech.com>,
 PHP Internals <internals@lists.php.net>
Date: Fri, 31 Oct 2014 09:25:51 +0000
To: Sherif Ramadan <theanomaly.is@gmail.com>
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: ajf@ajf.me (Andrea Faulds)


> On 31 Oct 2014, at 02:54, Sherif Ramadan <theanomaly.is@gmail.com> wrote:
>=20
> 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 th=
e
> concerns and hope to address them as clearly as possible.
>=20
> 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 th=
e
> language.

This is no less of a backwards-compatibility headache. This still breaks eve=
ry PHP app I have ever written.

>=20
> 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.
>=20
> So let's consider the following interface layout and some sample
> implementations as a start...
>=20
> https://gist.github.com/srgoogleguy/f729053e3e88b2d2b3ec
>=20
> 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 an=
d
> this can be easily extended by userland.
>=20
> 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.

No no, I'm not concerned about the contents of the interface. I'm wondering w=
hat, exactly, this "interface" does? I don't see how a mere interface would r=
eplace the superglobals, unless you want a superglobal request object that a=
nyone can swap out, which sounds like a bad idea.

--
Andrea Faulds
http://ajf.me/=