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

> On 13 Mar 2020, at 20:39, Paul M. Jones <pmjones@pmjones.io> wrote: > > Hi Stephen, > >> On Mar 13, 2020, at 02:41, Stephen Reay <php-lists@koalephant.com> wrote: >> >> I realise this is just bike shedding - the naming seems quite odd to me. >> >> This extension and the classes it provides are inherently about HTTP requests made to a php >> ‘server’, and the response it sends back - and yet it’s called Server{Request,Response,Buffer} >> etc…. The “server” part is superfluous in the context of a php web application, because it’s >> all “server” side, and while uncommon it’s not impossible to write *other* types of network >> server using PHP. > > I share your feeling here, and I don't think it's bike shedding. The naming is still > an open question on the RFC. > > I mentioned some other candidate names here ... > > https://externals.io/message/108436#108702 > > ... and re-reading your comment above, it looks like you saw that one. > > 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? > > Let me know, and thanks for bringing it up! > > > -- > 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > 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. However, that also may be confusing if people expect it to be a construct for making outgoing requests. 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). 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. Cheers Stephen