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

From: Date: Fri, 13 Mar 2020 18:40:36 +0000
Subject: Re: RFC: Server-Side Request and Response Objects (v2)
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to internals+get-109003@lists.php.net to get a copy of this message
> On Mar 13, 2020, at 10:55 AM, Paul M. Jones <pmjones@pmjones.io> wrote: > > 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? One issue that I have is, if we are going to fine-tune the naming to make sure it matches *exactly* then I think that CurrentRequest->server does not make sense. Maybe if you choose one of these names you should break out the server-specific items into their own class/object? -Mike

« previous php.internals (#109003) next »