Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78522
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <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>
	<5EFB26B9-E8C0-4F99-93D2-85A9FA4B674D@ajf.me>
Date: Fri, 31 Oct 2014 13:24:27 -0400
Message-ID: <CAL+t6cGCJGJa0uLfdJMerw0ogzRP3MULhzu7EPA0WsYOu8pj2A@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Larry Garfield <larry@garfieldtech.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01228626e2c48d0506bb441c
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: theanomaly.is@gmail.com (Sherif Ramadan)

--089e01228626e2c48d0506bb441c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Oct 31, 2014 at 12:04 PM, Andrea Faulds <ajf@ajf.me> wrote:

>
>
>
> 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??
>

No, by overriding the parseBody or parseParameters methods, for example,
you can prevent the default behavior from happening. (i.e. it is not doing
the same thing twice). Simply by extending the HttpRequest class, we can
call on the child class instead. Any methods not implemented in the
extending class would be forwarded to the parent class as per normal PHP
inheritance rules.


>
>
> OK. So they=E2=80=99re just interfaces, then? In which case, why not leav=
e the
> PHP-FIG to finish its HTTP Message proposal instead?
>
>
>
*snip*


> 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 interfa=
ces 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 o=
f 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 doe=
s this fix
> superglobals?
>
>

 Competing ideas are good and the very reason that drives innovation. This
proposal is for both the interface and the implementing class, which can be
extended to create custom behavior in handling the HTTP request/response. I
have no idea why you think PHP-FIG or PSR is involved in this conversation.
This is a PHP internals matter and should be considered for PHP internals
purposes. The benefits and cons of this proposal are pretty clear, I think.
You get the ability to handle different kinds of requests as you see fit or
you leave the default behavior intact and everyone wins.

The only thing you don't get if you do this in userland instead, is you
have to do the parsing of the message twice, which this RFC attempts to
circumvent, but offering a way to overrride the parser before parsing takes
place (if you choose to implement it).

--089e01228626e2c48d0506bb441c--