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-li...@koalephant.com> wrote:
>
>> On 13 Mar 2020, at 20:39, Paul M. Jones <pmjo...@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
pmjo...@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
