Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78526
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.27 cause and error)
Message-ID: <5453D6D5.2070705@garfieldtech.com>
Date: Fri, 31 Oct 2014 13:37:09 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: internals@lists.php.net
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>	<5453B114.6050400@gmail.com>	<CAL+t6cFCToJJGiCb8JhNe9oQws5UuBdKw+ot3rjUBQQr=7=Bxw@mail.gmail.com>	<5453C250.8090803@gmail.com>	<CAL+t6cEH7PPMu2G=e4NQau-iOznkG31-d187EMCDY0LFeew68g@mail.gmail.com>	<CABRjmp-b1jGD1SBTxmnJFLKi++WbL4TBggijN+VfSjRjPMJYPQ@mail.gmail.com> <CAL+t6cF7t7shs78xSiBfGxZSCqh5zcU-B_WWjK5J9ebiB=PTQA@mail.gmail.com>
In-Reply-To: <CAL+t6cF7t7shs78xSiBfGxZSCqh5zcU-B_WWjK5J9ebiB=PTQA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: larry@garfieldtech.com (Larry Garfield)

On 10/31/14, 12:38 PM, Sherif Ramadan wrote:
> On Fri, Oct 31, 2014 at 1:32 PM, Florian Margaine <florian@margaine.com>
> wrote:
>
>> Hi,
>>
>> Le 31 oct. 2014 18:28, "Sherif Ramadan" <theanomaly.is@gmail.com> a écrit
>> :
>>>
>>> On Fri, Oct 31, 2014 at 1:09 PM, Rowan Collins <rowan.collins@gmail.com>
>>> wrote:
>>>
>>>>
>>>> Let me repeat my question:
>>>>
>>>> Say I write a class "AwesomeHTTPReceive implements HttpMessageReceive",
>>>> what do I then do with this class in order for it to perform any
>> actions?
>>>>
>>>> How does PHP know that my class is the one it should populate, or when
>>>> that population should happen?
>>>>
>>>
>>>
>>> It wouldn't. You would need to extend the base class, since it already
>>> implements the necessary interface. PHP would simply call on the last
>>> subtype of HttpRequest during the request init phase.
>>
>> What if there is multiple subtypes?
>>
>> class A extends HttpRequest {}
>> class B extends HttpRequest {}
>>
>> What happens there?
>>
>
> As of now, all the subtypes would be called, i.e. if A has a receiveMessage
> method, it would be handed the message, and if B has a receiveMessage
> method it too would be handed the message. It's up to those methods to call
> on subsequent parsing methods to do something with the message, obviously
> any methods they don't implement are forwarded to the parent.
>
> This clearly has some conflicts, like if default parsing is left we
> overwrite superglobal variables. However, it also has benefits, in that we
> can have multiple implementations for handling the request in the same code
> base and it is left up to the user to decide which one to use.
>
> So, again, this is still a draft and I'm open to suggestions about how to
> handle/deal with such problems.

I think the root problem is that you're solving an issue that doesn't exist.

You're talking about providing alternate ways to parse the raw HTTP 
stream into user-accessible variables, ie, by pushing them into an 
object of a known interface rather than/in addition to the superglobals.

In my 15 years of writing PHP I have never wanted to change the way the 
raw HTTP is parsed.  I have, however, frequently wanted to have the data 
accessible in a more logical, semantic, and HTTP-correct way.  ($_GET is 
not about HTTP GET, it's about URI query parameters. $_POST isn't about 
HTTP POST, it's about application/x-www-form-encoded.  Etc.)  And I've 
wanted that information available in a non-global, OOP-injectable way. 
But I've never once had any desire to change the way an 
application/x-www-form-encoded is parsed.

Implementation problems aside, your proposal is not solving an extant 
problem.

If we want to improve PHP's HTTP handling, then having an object that 
exposes the HTTP request in a more logical fashion would be far more 
useful, and/or providing that data in a more logical way so that someone 
in user-space can provide that data in a logical fashion (eg, via a 
PSR-7-implementing object.)  I already stated in an earlier email what I 
felt would be most beneficial for internals to do toward that goal 
(specifically, clean up the streams API so that we can use it directly 
from an OOP world rather than a 1980s C world.)

IF internals wanted to add implementation, not just improving streams, 
something like the following would be much more useful:

$request = http_get_request(PHP_STDIN); // or something

Where $request is an object that implements the PSR-7 RequestInterface 
(or at least the read-only parts of it), or something similar.  Then 
implementers can compose that object however they want.

Although at least for the near term I think it's better to not do that 
and just do the lower-level plumbing to make FIG's work with PSR-7 easier.

--Larry Garfield