Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108661
To: php internals <internals@lists.php.net>
References: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io>
 <CANUQDCiP31aEqULqeGpN66ESHarKxWuXgQt_CqWeCLZc+1L-fA@mail.gmail.com>
 <5904137.fSVIMsojiJ@mcmic-probook>
 <CDBA02D0-07E1-4723-947C-22B403E650C0@pmjones.io>
 <CA+hqhpcOqCqXuOh3bWavJ+pZ5VVhekUO9LkKgd9c+b98VVnZSA@mail.gmail.com>
 <CAG9XoMRm2Nqjg3UbCc5=1_8m2W7qf8QRoSVk6d_qENJCKE1=9A@mail.gmail.com>
 <fcf43463-f9f7-4235-a84b-658074772ed7@www.fastmail.com>
 <3DDBFBA4-8D3A-46C5-9A10-B093A5E2386B@pmjones.io>
 <54493258-B52E-442A-A11D-82E1D4C7DE5E@gmail.com>
 <8264F6CF-AD55-41E2-9F5A-DAE8942E2B79@pmjones.io>
Message-ID: <f58eea0a-6d71-be57-c0b8-abc4321cdb38@gmail.com>
Date: Tue, 18 Feb 2020 20:21:17 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <8264F6CF-AD55-41E2-9F5A-DAE8942E2B79@pmjones.io>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
From: rowan.collins@gmail.com (Rowan Tommins)

On 17/02/2020 15:55, Paul M. Jones wrote:
> I apologize in advance for the length of this email. I hate reading walls-of-text, but the answers are necessarily long. I have tried to break it up into bullets where possible for easier reading.


No, thank you for taking the time to respond. I've cherry-picked 
rearranged the quotes in this reply a bit so I can try not to repeat 
myself too much; let me know if I've taken your words too far out of 
context.


> ...it is likewise valid to say that AdoDB "took functionality that was scattered across a dozen different vendor-specific extensions with different naming and calling conventions, and centralised it into one more-or-less consistent interface." So did PEAR DB, Metabase, MDB, and so on. PDO did it as an extension, instead of in userland, but the goals and outcomes noted were identical.


That's a fair point, everything PDO does could be and has been done in 
userland. There is one thing that couldn't be done outside of an 
extension, though, which is that PDO doesn't rely on the legacy 
extensions, it (in theory at least) replaces them.

What I think is slightly more relevant, is that PDO makes writing 
wrappers like ADODB easier, because it contains non-trivial 
functionality that those wrappers would otherwise have to write.


> I don't *expect* anything from existing published library authors
> ...
> I always thought of the "intended audience" as the much the same as 
> for any RFC


I think perhaps my choice of words has caused a bit of confusion. 
Perhaps "hope" would have been better than "expect", and "use cases" 
better than "intended audience".

I was trying to draw out two pieces of information:

- What's the sales pitch - what do YOU think is great about these classes?
- When working out the details, what code should we be picturing using 
the new classes?


I wasn't around when PDO was proposed, but an imaginary "sales pitch" 
might have gone something like this:

- Developers should be able to implement multiple database systems 
without learning the quirks of each vendor's extension
- Library authors shouldn't need to implement the basic functionality of 
every driver from scratch when the vendor could do it for them
- Vendors shouldn't need to decide which API to follow, when we can 
normalise everything internally
- We can offer different result formats and error-handling models out of 
the box
...and so on



>    - some [library authors] may find their own work so close to this extension that they migrate over to it entirely.


So, there is at least some hope that this will entirely replace some 
people's existing libraries, even if it doesn't replace the more 
powerful ones like HttpFoundation. That's probably reasonable.

(Note that I've been thinking of "library" fairly loosely - a single 
class used in a completely private monolithic repo, but which is written 
to be generic functionality, has much the same role as a public composer 
package in this case.)



> For myself, and as noted by Jan Schneider and others, those benefits center around...


This is what I was looking for. Sell it to me! :)


> ...a built-in OO-ish request/response object set...


"OO-ish" is a wise choice of words here. One of the reasons I'm not 
terribly keen on this proposal - particularly the request half - is that 
I'm a bit of an OO purist. By that I mean that I prefer objects that 
have a strong responsibility, and encapsulate useful behaviour, rather 
than just spitting out what went in. The response part of the proposal 
is closer to "real" OO, IMO, because it includes behaviour like 
manipulating individual headers and cookies.

The lack of behaviour also makes it less useful to people writing their 
own request and response objects: if I have a copy of $_POST and want to 
put it in my own object property, why would I first pass it to a 
ServerRequest object, and then get it straight back out again, if the 
object isn't helping me do anything with that data?

That said, I know some people are happy with OO-ish code, some even to 
the extent of preferring stdClass to an array. So it's not unreasonable 
to say that this will appeal to developers who are less puritanical 
about objects than me.



> ...that does pretty much just what PHP itself already does...


As you say elsewhere, this is useful for helping people migrate to it. 
The flipside of that is that it ties us into past decisions, rather than 
evaluating whether those decisions are still what we want.

The approach in providing both $files and $uploads arrays is a good 
compromise - provide the new better way, but also an easy-to-migrate 
way. I'd love to see them named more distinctly, though, maybe even 
calling one of them "legacy". I'd probably also make them methods so 
that the data can be stored once (in the new format) and re-formatted on 
demand (again, objects as behaviour rather than data).


> ...easing their transition away from global state


This I find less convincing. To quote from further down the e-mail, I wrote:

>> ...you can do almost as much in that direction as the RFC by writing "$get=$_GET; unset($_GET);" The hard problem is that the entry point for a request is in global scope, not a main() or handleRequest() function.

and you replied:

> Another "hard" problem is carrying those values around in the system once they are decoupled from global state; the objects in this RFC purport to do so.


If all the object does is "carry around" a copy of the superglobal 
arrays, I can write it in about a dozen lines of code. Admittedly, the 
implementation wouldn't match anyone else's, but if I wanted 
interoperability, I would need to follow a standard like PSR-7, or match 
a popular existing library; this does neither.

Again, the response object is more powerful in this regard, because we 
can't currently pass around a list of prepared cookies and trivially 
output it to the client.

Along the lines of my previous message about decoupling concerns, I 
would personally like the response parts of the proposal split out and 
re-cast as a kind of "response buffer". That could be useful directly, 
and it could provide useful functionality to people implementing a full 
PSR-7 or similar Response object.



> I had considered mentioning the dual OO+procedural APIs of mysqli, date, etc. but it seemed too much in an already-long RFC; I'm glad you brought it up, as I did have it in mind.


This is an interesting comparison to consider. Just as those extensions 
have procedural options for people who can't stand objects, the current 
proposal has objects for people who like "OO-ish".



>> Introducing these objects as part of a new calling convention for PHP scripts would definitely add value, and make them a true replacement for the superglobals, but that would be a very different RFC.
> That does seem rather ambitious. If you feel that's a valuable thing to add to PHP, perhaps it could be part of a future RFC, maybe even one that uses the objects in this RFC as a starting point.


One of the things I don't like about the current proposal is that it's 
modelled so closely around the current superglobals that I fear it would 
actually be *harder* to replace them.

I find this constraint particularly awkward:


> N.b.: It is up to you to make sure the various content-related header 
> values in |$GLOBALS| match the custom |$content| string.

Parsing a request body from an arbitrary source into arrays that match 
the structure of $_POST and $_FILES would be a really useful feature. It 
would be something userland libraries could make use of right now, and 
would fit in nicely with a future where those arrays aren't populated by 
default.


I also really want to see the day when I never have to interact with 
$_SERVER again. Other than renaming it, this object's design makes that 
less likely, not more.

Imagine if in future we're able to redesign the internals so that there 
is a dedicated and reliable field for the requested URL; the current 
object doesn't have anywhere we can put that. If we add it later, it 
will be too late, code will be written that passes around ServerRequest 
objects, but relies on the full array of CGI variables to reconstruct 
the URL.

If this object took a more opinionated view of what behaviour to 
encapsulate, we could simply hide the "server" array completely. Common 
use cases would be exposed via methods, and rarer use cases would have 
to be added in userland with their own copy of $_SERVER. Then my dream 
of deprecating $_SERVER could mean something other than moving it into 
an object.


I hope I haven't left any unfinished sentences as I went back and forth 
through this! And thanks again for taking the time to engage with me.

Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]