Hi Rowan, > On Mar 4, 2020, at 17:13, Rowan Tommins <rowan.coll...@gmail.com> wrote: > >> On 04/03/2020 20:01, Paul M. Jones wrote: >> >> This RFC, in contrast, does not attempt to model HTTP messages. It does not >> attempt to discard previous ways of working. Instead, it proposes a more >> object-oriented representation of functionality that already exists in PHP, >> honoring that previously-existing approach. There is quite a bit of >> real-world experience as to how well it will work, since it takes into >> account many commonalities between existing userland projects. Thus, what >> the RFC purports to get close to is that existing way-of-working, and I >> think it succeeds about as well as can be possible for its goals. > > This is something you have said a few times, and is definitely a worthy goal, > but it's not something that comes across very strongly in the RFC itself. > There is a comparison to Symfony HttpFoundation, but it mentions as many > differences as similarities; and there is a list of 13 other implementations, > but no information on how this proposal compares to them. > > I suspect that's just because you didn't want to burden the RFC with too many > details, but if you have any notes about what functionality is common in > existing libraries, perhaps that could be posted somewhere as a kind of > appendix to show where the current design came from?
Your suspicion is correct; I thought the RFC was pretty long as it was. And your suggestion is a good one; here is a Google Sheets doc of summary findings (copied from my local spreadsheets): https://docs.google.com/spreadsheets/d/e/2PACX-1vQzJP00bOAMYGSVQ8QIIJkXVdAg-OMEfkgna7-b2IsuoWN8x_TazxEYn-yVDF2XQIqnzmHqdDO3KEKx/pubhtml When you see $foo, it means the feature is presented as a property, or as a method on a public property object. When you see foo(), it means the feature is presented as a public method on the object itself. Other notes: 1. On the Request and Response objects, I have a line for "nominal public mode": - A nominal "readonly" is for the superglobal-derived public properties. The object might include one or two mutable properties, but those properties are application-specific, not superglobal-derived. Gurther, the superglobal-derived properties might be mutable within a protected scope but not a public one. - A nominal "mutable" means the superglobal-derived values are mutable from public scope. - A nominal "immutable" means the object is intended to be immutable (whether it succeeds or not). - Of the 14 projects, 8 have nominally readonly Request objects, and all but one Response object are mutable. 2. Several projects retain "Forwarded" information internally on the Request objects, but almost none of them expose it publicly. As it appears to be an commonly-calculated set of values, I did include it in ServerRequest, and made it available for public reading, so that extenders/decorators can use it. 3. Likewise, several projects expose a "client IP" or "remote address" value, but don't calculate it the same way. So even though it's a common need, and I'd like to have it in ServerRequest, there's not broad agreement on what that value ought to be. 4. Finally, several projects have some kind of Response cache methods, usually in the form of setCache() etc., and then often with individual cache directive methods. I recall that they differed in how they retained the caching information; some wrote to headers directly, others retained the directives individually and "compiled" them into a caching header at sending time, etc. So while I would like to incorporate the caching stuff into ServerResponse, I don't think there's enough commonality between the implementations to warrant that. I hope the rest of it is self-explanatory, or easily-understood; if not, let me know, and I'll answer your questions. And of course, if you notice discrepancies or inaccuracies, tell me so I can correct them. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
