Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78516
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)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
In-Reply-To: <CAL+t6cGanxv3dJONcECupw6Cfzup4s6At6tEcK_=Qagn67RNjw@mail.gmail.com>
Date: Fri, 31 Oct 2014 16:04:42 +0000
Cc: Larry Garfield <larry@garfieldtech.com>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <5EFB26B9-E8C0-4F99-93D2-85A9FA4B674D@ajf.me>
References: <CAL+t6cGt8B+X4ptWbyo6zm_xoyBOJC4QeiH6DjCxHX11CPWm_g@mail.gmail.com> <5452B87B.5040009@garfieldtech.com> <CAL+t6cHqQL-TaurfG887qxeyeVZPCxQcnY_BrtD-oHCS196HQw@mail.gmail.com> <0B797CE3-7AFA-4330-9A98-D3CAFC6D6072@ajf.me> <CAL+t6cGanxv3dJONcECupw6Cfzup4s6At6tEcK_=Qagn67RNjw@mail.gmail.com>
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 14:30, Sherif Ramadan <theanomaly.is@gmail.com> =
wrote:
>=20
> To be perfectly clear, the default behavior would remain the same, so =
no PHP app you have ever written would break. The difference is, you =
would now be able to override any part of the default behavior by =
extending the HttpRequest class in your own code.

So there=E2=80=99s still a default implementation, then? So, if you want =
to parse in userland, how does that work? The default implementation =
fills in the variables and then your implementation parses it again, =
wasting CPU time and making the request take longer? Or does the default =
implementation do nothing at all unless asked to, breaking existing apps =
unless they=E2=80=99re modified to request parsing? Or is it =
INI-determined??

> The interfaces do exactly what you see here. They specified which =
methods the HttpRequest and HttpResponse objects must implement.

OK. So they=E2=80=99re just interfaces, then? In which case, why not =
leave the PHP-FIG to finish its HTTP Message proposal instead?

> If you bothered to invest nearly as much time in reading the updates =
to the RFC as you did to making blanket statements and objections, you =
might actually find less reason to respond with objections so abruptly. =
The HttpRequest and HttpResponse classes are intended to provide a =
central place for message handling behaviors and their properties can be =
used to describe these behaviors.
>=20
> So, if you wanted to support a $_PUT superglobal, rather than adding =
one to the language, you can simply add the behavior to do the =
processing of PUT requests in your HttpRequest class, by extending =
HttpRequest and defining how PUT variables are handled there.

So, all you=E2=80=99re proposing is a set of interfaces, to compete with =
the work the PHP-FIG is doing.

I don=E2=80=99t see how this is useful. How, exactly, does adding =
interfaces solve the problems with superglobals? Because you=E2=80=99re =
creating a common standard for alternative request implementations? But, =
we already have such a WIP standard in userland from the PSR people.

I really don=E2=80=99t get this RFC. If this was to add implementations =
of the PSR Request/Response stuff, that might be useful. But merely =
adding new interfaces=E2=80=A6 I don=E2=80=99t get it. Why duplicate =
effort? How does this fix superglobals?

--
Andrea Faulds
http://ajf.me/