Re: New Standardized HTTP Interface
| From: | Andrea Faulds | Date: | Fri, 31 Oct 2014 09:25:51 +0000 |
| Subject: | Re: New Standardized HTTP Interface | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-78503@lists.php.net to get a copy of this message | ||
> On 31 Oct 2014, at 02:54, Sherif Ramadan <theanomaly.is@gmail.com> wrote:
>
> 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.
This is no less of a backwards-compatibility headache. This still breaks every PHP app I have ever
written.
>
> 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.
No no, I'm not concerned about the contents of the interface. I'm wondering what, exactly,
this "interface" does? I don't see how a mere interface would replace the
superglobals, unless you want a superglobal request object that anyone can swap out, which sounds
like a bad idea.
--
Andrea Faulds
http://ajf.me/