Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69457
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.215.10 cause and error)
To: Florian Anderiasch <ml@anderiasch.de>
Cc: Daniel Lowrey <rdlowrey@gmail.com>, "internals@lists.php.net"
 <internals@lists.php.net>
In-Reply-To: <524C4006.9060106@anderiasch.de>
References:
	 <CAH8MpnkB42pmuZLOAbETj=v2kGXODkwfPewW57XehAB77wUY7g@mail.gmail.com>
	 <524C4006.9060106@anderiasch.de>
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 02 Oct 2013 17:56:16 +0200
Message-ID: <1380729376.19591.26.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: HTTP supergloblas and request body/query (was:
 Parsing PUT data)
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On Wed, 2013-10-02 at 17:47 +0200, Florian Anderiasch wrote:
> On 02.10.2013 17:29, Daniel Lowrey wrote:
> > The superglobals are a hopelessly poor abstraction. Can we stop trying to
> > put the proverbial gold ring in the pig's snout on this?
> >
> > [...]
> >
> > Something like the following would be an infinitely superior solution:
> > 
> > interface HttpRequest {
> >     function getMethod();
> > [...]
> > }
> > 
> > By adding a global function such as `get_request()` that returns the
> > immutable request object you get all the functionality you could want:
> > 
> > 1. Entity body parsing (for cookies or form data) could be done JIT
> > 2. Userland code can easily typehint against the request
> > 3. No more mutability, eminently testable
> > 4. Eliminates the need for `$_GET`, `$_POST`, `$_COOKIE`, etc ...
> > 
> > This is simply an example of a much better way to model HTTP requests --
> > it's not a suggestion for a final implementation. But IMO if we're going to
> > fix this then we should really fix it and not continuously tickle the same
> > broken abstraction.
> 
> While I totally agree with your point, I don't see why this needs to be
> in core. This is perfectly done in userspace, even the immutable part.
> 
> The only benefit of putting that in core would be the standard-defining
> part, but not much else. Plus it's not minimizing any abuse, as long as
> the superglobals are still available (and I don't think renaming or
> removing them would be a good idea.

Also mind that filter_input() as an immutable API exists.

johannes