Re: RFC: Server-Side Request and Response Objects (v2)

Hi Dan, Thanks for taking the time to bring up your concerns. While I don't expect to change your mind (nice though that would be!) perhaps other readers here will find my counter-positions useful. > On Mar 3, 2020, at 16:58, Dan Ackroyd <Danack@basereality.com> 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. Not the *only* reason, though it's true that it would be difficult-to-impossible to do outside of C. As Rowan mentioned earlier, and as I opined in an unpublished version of the RFC, one other reason would be to provide a language-level OO-ish representation of PHP functions, similar to what ext/mysqli and ext/date do. > This is a hack I dispute the word "hack" -- a readonly feature is requested here from time to time -- though I do understand that it is an uncommon approach. > that would confuse a lot of developers I think you're right that it might confuse some developers, but I also opine that just as many or more would "get it" either right away or very quickly. > and instantly be added to most lists of "how PHP is bad". Adding one point to the many thousands that already exist on such ill-considered lists, so not much of a change there. ;-) > 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 > > ... > > 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. All of your points are completely true. In fact, they are true for every RFC presented on this list; past, present, and future. So while you're correct, I have a hard time seeing it as a criticism specific to this proposal. (I'd be happy to see refinement of your points toward more specificity, if feel so inclined.) Having said that, I'll present a past example that may tie it more specifically to this RFC. The Same Site Cookie proposal <https://wiki.php.net/rfc/same-site-cookie> hits around the points you mention: a change to long-standing behavior that might have entailed a BC break, discussion of that change, and code compatibility. All of those were managed quite successfully and in a reasonable timeframe. And although you voted against that proposal, it did pass, and has turned out to be pretty good; I imagine the same kind of change-success, if it is ever needed after adoption, is just as likely for this RFC as well. > 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. I know you're not especially a fan of PSR-7 <http://basereality.com/blog/17/PSR7_and_airing_of_grievances> so arguing in its defense, against interest, is laudable. Good form! But your phrasing about this RFC "being even as close as PSR-7 was" raises the question: "as close" to what? The PSR-7 interfaces, and their many differing implementations, attempt to model HTTP messages as immutable objects. Indeed, the PSR-7 design process ended up discounting and discarding all pre-existing ways-of-working in PHP land, to the point of ignoring all previous implementations in the FIG member projects and elsewhere. Instead, PSR-7 declared "year zero" and presented an entirely new way of working that was completely different from and unrelated to anything else in PHP-land at that time. (For a brief history of the PSR-7 design evolution, see the first few slides of my talk on PSR-7 and ADR at <http://paul-m-jones.com/talks/psr7adr.pdf>.) Among other things, that meant there was no applicable real-world experience as to how well PSR-7 would work in the mid-to-long term. That historical context may make it easier to see why "a huge amount of energy was spent designing PSR-7", while resulting in something that was "definitely not a perfect design", in order to get close to a model of HTTP messages. 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. > 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 I will add this to my reading backlog; thanks for the recommendation! -- Paul M. Jones pmjones@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