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

Hi Stephen, Good stuff. You have stepped through my & John's earlier thought-process in much the same way that led to the current naming. > On Mar 13, 2020, at 09:23, Stephen Reay <php-lists@koalephant.com> wrote: > >> On 13 Mar 2020, at 20:39, Paul M. Jones <pmjones@pmjones.io> wrote: >> >> Do you have alternative suggestions or preferences on the names? Or, do you feel that >> "Request" and "Response" and "ResponseSender" (without any prefixes at >> all) would be sufficiently obvious? > > Hi Paul, > > TLDR: if you aren’t concerned about the concept of php-initiated outgoing HTTP requests, I > think HTTP{Request,Response,Buffer} is quite clear in terms of > naming. If you wanted to be more explicit about their purpose (and/or prevent possible confusion > with either user land or potential future extensions handling outgoing requests), > IncomingHTTPRequest and > OutgoingHTTPResponse are very explicit, if a bit verbose. > > I think I did see that message, but I must admit I haven’t followed all the responses in the > discussion. > > Personally I think HTTP makes a pretty obvious prefix (I’m > not gonna get into a capitalisation debate), because these things are explicitly related to HTTP > request and response messages. I follow your reasoning. The main problem I see with "HTTP" (I won't argue capitalization either) is that I can guarantee you there will be a very vocal subset of users who will complain loudly and continuously that the objects do not model HTTP messages. I would prefer to pre-empt that, especially since it is true. ;-) One other alternative John & I contemplated was Web{Request,Response,ResponseSender} -- do you think that might be a reasonable alternative to HTTP, one that is "adjacent" but not overly-specific? That would net us: - WebRequest - WebResponse - WebResponseSender I didn't like the look of it previously, and I don't think I like the look of it now, but ... (/me shrugs). > However, that also may be confusing if people expect it to be a construct for making outgoing > requests. Yes, that's another tricky bit in the naming -- making a distinction between the objects as representative of client operations (send request, receive response) and server operations (receive request, send response). Thus the current Server prefix (however unsatisfactory it may be) to indicate their operational context. Your Incoming and Outgoing prefixes, minus the HTTP, would net us: - IncomingRequest - OutgoingResponse - OutgoingResponseSender I will need to ponder on those. > The user land implementation I’ve been using ’solves’ this by using a > HTTP namespace, and then provides > Request and Response (for an > outgoing - i.e. curl - HTTP Request, and the corresponding HTTP Response) objects and then > CurrentRequest and CurrentResponse > for what your RFC proposes (i.e. the active request made to php). Yes, userland does operate that way. However, I think adding an HTTP namespace to PHP itself is something to be avoided, so emulating userland here is not an option. > As with anything any of us has written, I’m not 100% sold on ‘Current{Request,Response}` > even after writing it, but I think it’s at least a little more specific about what they do, when > the namespace is taken into account. Current{...} is not something we had previously considered; that would net us, in the global namespace: - CurrentRequest - CurrentResponse - CurrentResponseSender I will need to ponder on those as well. Any further thoughts or opinions on this, Stephen? Or from anyone else? -- 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