Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

This is only part of a thread. view whole thread
February 11, 2020 16:58 (Ben Ramsey)
> On Feb 10, 2020, at 10:18, Paul M. Jones <> wrote: > > Hi Internals, > > After a couple of years of incubation, I am happy to offer a second version of this RFC: > > > > It proposes an object-oriented approach around request and response functionality already existing in PHP, in order to reduce the global-state problems that come with superglobals and the various response-related functions. > > The SQLite "about" page says, "Think of SQLite not as a replacement for Oracle but as a replacement for fopen()." <> Likewise, think of this RFC not as a replacement for HttpFoundation or PSR-7, or as a model of HTTP messages, but as an object-oriented alternative to superglobals, header(), setcookie(), setrawcookie(), and so on. > > Thanks in advance for your time and consideration while evaluating it.
Regarding the array of arrays for $accept* and $forwarded, what are your thoughts on using value objects with properties, rather than arrays with keys? AcceptValue * string $value * string $quality * array $params * ?string $type * ?string $subtype ForwardedValue * string $by * string $for * string $host * string $proto Cheers, Ben
February 13, 2020 02:08 (Paul M . Jones)
Hi Ben,

> On Feb 11, 2020, at 10:58, Ben Ramsey <> wrote: > > Regarding the array of arrays for $accept* and $forwarded, what are your thoughts on using value objects with properties, rather than arrays with keys?
It's a fair suggestion, but I am not keen to expand the number of new declarations any more than necessary. To play with your idea a little bit, let's say we start with ... - ServerRequest - ServerResponse - ServerResponseSender .... then to bring in Jan Schneider's suggestion, we add ServerResponseInterface (4 classes). Then we add the value objects themselves: ServerRequestAcceptValue and ServerRequestForwardValue. That's 6 classes. That's maybe not so bad. But, once we start down this path, it's easy for me to imagine what comes after. For example, since we're trying to do "the right thing," someone will suggest to typehint the properties "correctly." Instead of arrays of value objects, they probably ought to be collection objects. That gets us ServerRequestAcceptValueCollection and ServerRequestForwardValueCollection, and we're at 8 classes. Then someone is likely to say that there ought to be interfaces for all those so their implementations can get swapped out. That's ... - ServerRequest - ServerResponse - ServerResponseInterface - ServerResponseSender - ServerRequestAcceptValue - ServerRequestAcceptValueInterface - ServerRequestAcceptValueCollection - ServerRequestAcceptValueCollectionInterface - ServerRequestForwardValue - ServerRequestForwardValueInterface - ServerRequestForwardValueCollection - ServerRequestForwardValueCollectionInterface .... 12 classes and interfaces. And probably not done yet, once others really sink their teeth into it. Now, that's not a *wrong* approach -- but it does seem like overkill to me. Or, we could avoid starting down that path and stick with arrays, which in ServerRequest are read-only and immutable and get us all the things we actually need for our daily work here. Of those two, I prefer the minimalist approach of arrays for this RFC; the "effort-to-benefit" ratio is much better. -- Paul M. Jones Modernizing Legacy Applications in PHP Solving the N+1 Problem in PHP