Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78482
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.179 as permitted sender)
Message-ID: <54528E33.2040909@gmail.com>
Date: Thu, 30 Oct 2014 19:14:59 +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: internals@lists.php.net
References: <CAL+t6cGt8B+X4ptWbyo6zm_xoyBOJC4QeiH6DjCxHX11CPWm_g@mail.gmail.com> <CABRjmp9p=+zGiqn_nuVJcDAK0po98FnDhb7wTmG66tob4u0GOw@mail.gmail.com>
In-Reply-To: <CABRjmp9p=+zGiqn_nuVJcDAK0po98FnDhb7wTmG66tob4u0GOw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: rowan.collins@gmail.com (Rowan Collins)

Florian Margaine wrote on 30/10/2014 18:30:
> Hi,
>
> On Thu, Oct 30, 2014 at 7:23 PM, Sherif Ramadan <theanomaly.is@gmail.com>
> wrote:
>
>> Since it's an interface, it only dictates the facilitation of PHP's
>> built-in functionality and the user's desired implementation, but no the
>> implementation itself.
>
> I find this very... useless. Sure, interfaces are not useless. But I don't
> think php-src is there to dictate what userland code should look like. It
> should provide *implementations*, not interfaces.

Agreed, I still don't understand the purpose of SplObserver and 
SplSubject, for instance. To be fair, it's not clear from this early 
stage whether the RFC is going to define interfaces with a special 
relationship to core, more like Countable or Iterable.


> The other thing I don't like in your RFC is the removal of superglobals.
> Sure, they're not the best interface out there, but breaking *every single*
> codebase out there is not the way to go. Especially if we don't want a
> perl6/python3-like failure to adoption.

Yes, this; 1000 times this! I will lay you a bet that if the RFC reaches 
a vote with the intention to remove superglobals in tact, it will not 
pass. If that is removed and it provides a useful alternative to 
superglobals, that allows things not currently possible (e.g. callback 
request-response patterns, rather than the current 
one-process-per-thread CGI-style model), then it might be useful.

If all you're after is standardised handling in userland, then this is 
better addressed to PHP-FIG to publish an advisory set of interfaces 
that major frameworks can transition to from whatever handling they have 
currently.

-- 
Rowan Collins
[IMSoP]