On Fri, 28 Feb 2020 at 15:25, Paul M. Jones <pmjo...@pmjones.io> wrote:
> Are there any members here who currently expect to vote "no", who have not > yet chimed in? I'd like to hear your criticisms and objections, so I can at > least attempt to resolve your concerns. > I expect to vote "no". My thoughts are: 1. The chosen API. We have an OO approach, but headers and query parameters are accessed through an array-style mechanism. I'm not a fan of the way everything maps onto ServerRequest, with certain $_SERVER vars promoted to be part of it (but not all AFAICT). 2. The OO-ish approach. For a core feature which will be around for 20+ years I would like a pure(r) OO approach taken, and time to be taken to get that right. What you have is pragmatic, but as I say in (1) not something I'm a fan of. Rowan Tommins on 18 Feb 2020 at 20:21 expressed this well (link: https://externals.io/message/108436#108661). 3. WRT the RFC: a) there is no section on where this came from. With your involvement in PSR-7 it looks to be an area you've given much thought to. Why did you develop ext/request? What problem(s) did you see that this is the answer to? I skimmed the thread but didn't pick out a clear answer to this. b) Did you look at how other languages and/or frameworks deal with requests and responses, and was there inspiration and lessons you took from their successes (or failures)? [For me this is a key omission in most PHP RFCs] Thinking about porting existing codebases across, ServerRequest holding copies rather than references would make it hard to interop with existing code using the superglobals. I've had this rewriting legacy apps that use $_SESSION and the new framework uses an OO session handler; it's not fun but with references can usually be made to work. In this case, what would the migration path look like? Johannes Schlüter commented on this on 24 Feb but I didn't understand his comment (link: https://externals.io/message/108436#108737). In summary, I like the idea of steering people away from superglobals, appreciate the work you've put in, and am not persuaded by the approach. Peter
