Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:78525 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 18536 invoked from network); 31 Oct 2014 17:38:20 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 31 Oct 2014 17:38:20 -0000 Authentication-Results: pb1.pair.com header.from=theanomaly.is@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=theanomaly.is@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.182 as permitted sender) X-PHP-List-Original-Sender: theanomaly.is@gmail.com X-Host-Fingerprint: 209.85.212.182 mail-wi0-f182.google.com Received: from [209.85.212.182] ([209.85.212.182:61004] helo=mail-wi0-f182.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id AC/A7-15608-A09C3545 for ; Fri, 31 Oct 2014 12:38:19 -0500 Received: by mail-wi0-f182.google.com with SMTP id d1so1911371wiv.15 for ; Fri, 31 Oct 2014 10:38:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k4sZ4f9S0pWfndVV/IVhkD+fVmzXmV7jxGf4+0towbM=; b=Atgau/ZkIpiAw6+ZCIZsQs6O8xdPhBS5MMb6lfnLwRDWpqzXUVBoLNIV5Ny+nmE8H+ 26s0kLbcbwg7CYJDZJSXagOjJ4EgpVZexKdhcCZ4K87+OH02WeOx8RslS+cAAMQ01qhg 8SInG73dCop4SjFnRvQMVHIvRAIhHAk7psNv3qQ49aLXTb49vSJD+sDcAa8xxz6idsYC RH6/5kfUpzaq9syya2bXMattIOLp3RqqPokdE0Be2R7CFpDmo0VrhunhZV+6f+cAuFbe ksm1kh7I7dXnpyXsC+po2mCbR4tXrxnJ9Xl7Ga7Dzjg6jz1ysLvL0wzcCRIOm2R8Uv10 tlEg== MIME-Version: 1.0 X-Received: by 10.194.94.9 with SMTP id cy9mr4445681wjb.117.1414777095843; Fri, 31 Oct 2014 10:38:15 -0700 (PDT) Received: by 10.216.123.4 with HTTP; Fri, 31 Oct 2014 10:38:15 -0700 (PDT) In-Reply-To: References: <5452B87B.5040009@garfieldtech.com> <0B797CE3-7AFA-4330-9A98-D3CAFC6D6072@ajf.me> <5453B114.6050400@gmail.com> <5453C250.8090803@gmail.com> Date: Fri, 31 Oct 2014 13:38:15 -0400 Message-ID: To: Florian Margaine Cc: PHP Internals , Rowan Collins Content-Type: multipart/alternative; boundary=047d7bb047dc3bf9330506bb766f Subject: Re: [PHP-DEV] New Standardized HTTP Interface From: theanomaly.is@gmail.com (Sherif Ramadan) --047d7bb047dc3bf9330506bb766f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Oct 31, 2014 at 1:32 PM, Florian Margaine wrote: > Hi, > > Le 31 oct. 2014 18:28, "Sherif Ramadan" a =C3= =A9crit > : > > > > On Fri, Oct 31, 2014 at 1:09 PM, Rowan Collins > > 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 whe= n > > > 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. > > Of course, this is an > > implementation detail as of now. There could certainly be other/better > ways > > to accomplish this. I just want to keep it as simple as possible for no= w > > without introducing more configuration nightmares that people often > > complain about. I really don't like the idea of adding yet another INI > > directive to control this behavior (making it harder to port). > > > > What do you propose? > > Regards, > Florian Margaine > --047d7bb047dc3bf9330506bb766f--