Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:78531 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 34795 invoked from network); 31 Oct 2014 19:44:12 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 31 Oct 2014 19:44:12 -0000 Authentication-Results: pb1.pair.com smtp.mail=rowan.collins@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=rowan.collins@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.50 as permitted sender) X-PHP-List-Original-Sender: rowan.collins@gmail.com X-Host-Fingerprint: 74.125.82.50 mail-wg0-f50.google.com Received: from [74.125.82.50] ([74.125.82.50:47953] helo=mail-wg0-f50.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C3/AA-15608-B86E3545 for ; Fri, 31 Oct 2014 14:44:12 -0500 Received: by mail-wg0-f50.google.com with SMTP id z12so7221344wgg.37 for ; Fri, 31 Oct 2014 12:44:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=8zvZgUe6BJRYj1Ksx+PXeUt9BNd9PGebjqk3nInLHqs=; b=qgzF6A5suJIlLkv57oyF7414VtE8fi1PznZuLISfl23907RZpLis5kw5egjnkrzKbh /uyluwoTR6mYE6iDiVielt1+uw8iCXfonnWg2BLQ7icUJp0hk/ryrEeqA4VX1TAL3Y0r A63e48Cv+OV65aHEIw8xJvQ50jicPG9szKDtX2xArNlbP7Bm89F6m73bK2UXydJsBGE3 rsoKl/bZpDODrqvLEcW6VmtRdGghxZdc9q1TPXwNPm8iZNagVVeuIbsIpWIFio+a9LJc ORCS59x1JBlWROmuF5bOTQCve6FVRA3Ynwa7VJOF7kXV2iq8sFZZwHEOVGznQ8jWSjgI ta5w== X-Received: by 10.180.37.130 with SMTP id y2mr6034939wij.78.1414784648188; Fri, 31 Oct 2014 12:44:08 -0700 (PDT) Received: from [192.168.0.177] ([62.189.198.114]) by mx.google.com with ESMTPSA id t9sm13120825wjf.41.2014.10.31.12.44.07 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Oct 2014 12:44:07 -0700 (PDT) Message-ID: <5453E686.90309@gmail.com> Date: Fri, 31 Oct 2014 19:44:06 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: PHP Internals References: <5452B87B.5040009@garfieldtech.com> <0B797CE3-7AFA-4330-9A98-D3CAFC6D6072@ajf.me> <5453B114.6050400@gmail.com> <5453C250.8090803@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040403010102050003010305" Subject: Re: [PHP-DEV] New Standardized HTTP Interface From: rowan.collins@gmail.com (Rowan Collins) --------------040403010102050003010305 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sherif Ramadan wrote on 31/10/2014 17:27: > > > 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 > when that population should happen? > > > > It wouldn't. You would need to extend the base class, since it already > implements the necessary interface. If extending the base class is mandatory, then an interface should not exist. An interface's purpose is to define something's structure independent of an inheritance tree. However, this doesn't change the question, because "AwesomeHTTPReceive extends HttpMessageReceive" still doesn't tell PHP anything about when this class will be used. The only possibility it opens is that the base class could have a constructor (marked as final) which slurped the HTTP response out of some invisible superglobal whenever you ran "$foo = new AwesomeHTTPReceive" > PHP would simply call on the last subtype of HttpRequest during the > request init phase. It is not possible for a declarative piece of code to be discovered during the init phase without an ini setting or similar, because there is no way of knowing what files will be require()d during execution. Moreover, modern practice is to put each class in a separate file and use an autoloader, so a class is declared when it is first used. > Of course, this is an implementation detail as of now. There could > certainly be other/better ways to accomplish this. I think this detail is fundamental to how the proposal will work, and it is hard to proceed any further with the discussion without some idea of what mechanism would be used to tie the custom implementation into the engine/SAPI. > What do you propose? Nothing, it's not my RFC, and I am trying to understand what you intended by its proposal. -- Rowan Collins [IMSoP] --------------040403010102050003010305--