Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108838
User-Agent: Cyrus-JMAP/3.1.7-967-g014f925-fmstable-20200226v1
Mime-Version: 1.0
Message-ID: <102a320c-394c-4035-9611-aef59315072e@www.fastmail.com>
In-Reply-To: 
 <CA+kxMuSzrxsXBra7TkFSz9-qbfVVikjW-FBr8juEsSOFNDx+pQ@mail.gmail.com>
References: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io>
 <1657AB79-5CAF-4BCA-96B5-1343EC703CCD@pmjones.io>
 <CA+kxMuSzrxsXBra7TkFSz9-qbfVVikjW-FBr8juEsSOFNDx+pQ@mail.gmail.com>
Date: Tue, 03 Mar 2020 17:45:09 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Mar 3, 2020, at 4:58 PM, Dan Ackroyd wrote:
> Paul M. Jones <pmjones@pmjones.io> wrote:
> 
> > Are there any members here who currently expect to vote "no",
> 
> The only reason for doing this as C code appears to be make it have
> read-only properties. This is a hack that would confuse a lot of
> developers, and instantly be added to most lists of "how PHP is bad".
> 
> I really think this doesn't belong in core PHP. Tying this into core means that:
> 
> - BC breaking changes could only happen on major versions.
> 
> - Discussion of those changes would take up a lot of time, or more
> likely never happen. See all of our core extensions that are
> desperately in need of a maintainer to work on them.
> 
> - It might be impossible (or at least annoyingly difficult) to write
> code that was compatible with two versions of PHP, if they used this
> object.
> 
> As you were involved and so know, a huge amount of energy was spent
> designing PSR-7, and still it was definitely not a perfect design. The
> chances of the design of this API being even as close as PSR-7 was,
> seems minimal. Which means that we would be likely to regret bringing
> it into core.
> 
> For stuff to be added to core, to overcome the burden of supporting in
> the future, there needs to be a strong reason to add it. Not just
> something that could be done.
> 
> In case anyone is interested, there is a book called 'Systemantics'
> that's actually quite applicable to open source projects....despite
> being written before personal computers were really a thing:
> https://en.wikipedia.org/wiki/Systemantics#First_principles
> https://www.amazon.co.uk/Systems-Bible-Beginners-Guide-Large/dp/0961825170/ref
> 
> cheers
> Dan
> Ack

I don't have a vote, but here are my thoughts (and speaking only for myself, not on behalf of FIG or any other group):

Right now, there are effectively 3 ways of handling request/response information in PHP:

1) Raw super globals, possibly with proprietary bits on top.
2) HttpFoundation
3) PSR-7

Each has its own sub-ecosystem around it, which means that there are effectively 3 different, incompatible HTTP ecosystems.  (Or 2, depending on if you count the super globals as having an ecosystem.)

Paul has made it very clear that the goal of the RFC is not to supplant HttpFoundation or PSR-7, and there's no sign of plans to remove the superglobals any time soon (that would take at least 5 years/1 major of deprecation to phase out, even if we wanted to).  Being a better underpinning for HttpFoundation/PSR-7 is a non-goal of the RFC, and I agree it wouldn't really buy them much compared to pulling data from the superglobals.  That means there would effectively become 4 mini-ecosystems: HttpFoundation, PSR-7, superglobals, and ServerRequest.


If you only ever work on one framework or application, that doesn't really impact you much.  If you work on multiple, or are developing a library you want to be as agnostic as possible, or if you're just learning PHP, the addition of a 4th mini-ecosystem is a negative.

The RFC does, however, have some positives to it.  In particular:

* objects really are nicer to work with (subjective, but I usually find that to be the case)
* they discourage global behavior
* ServerRequest is read-only which avoids some bugs (but may make other things more difficult)
* using it exclusively gives you a nicer way to avoid buffer and header-already-sent issues

All of those could be said about PSR-7, of course, and all but the read-only point could be said about HttpFoundation.

The key question, then, is if on balance the positives listed above outweighs the negative of yet-another-mini-ecosystem around HTTP handling, does so by a large enough margin to justify its inclusion.

That is a balance question on which reasonable people can disagree.  For my part, I feel it is on net a negative, and thus should not be approved.

I am not against improving PHP's native HTTP handling; on the contrary, I would be very much in favor of a proposal that goes much further, with the aim that it can eventually deprecate PSR-7 and HttpFoundation, or at least large portions of them.  That is a substantially higher lift, of course; it would likely need to start with overhauling PHP's stream handling to make it cleaner and more OOPy, something that has been discussed on and off for years but with no serious movement yet.  That would be a topic for another RFC.

--Larry Garfield