Re: RFC1867 (multipart/form-data) PUT requests
| From: | Michał Marcin Brzuchalski | Date: | Wed, 28 Jun 2023 06:18:37 +0000 |
| Subject: | Re: RFC1867 (multipart/form-data) PUT requests | ||
| References: | 1 2 3 4 5 6 7 8 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-120707@lists.php.net to get a copy of this message | ||
Hi Andreas,
śr., 28 cze 2023 o 07:55 Andreas Heigl <andreas@heigl.org> napisał(a):
> ...
> While I like not adding more Superglobals, it seems like we are adding
> more and more functions to retrieve the different parts of a
> Request-Object...
>
> So when we are at it: Why don't we introduce exactly that? A
> Request-Object that has all the methods. And which is immutable.
>
> And one method
request(): \Request
>
I agree with the above, this would allow us to clean up the global
namespace in the future.
My personal use cases for PHP are mostly queue workers/event stream
consumers,
so the usual request/response model SAPI is used rarely. But I understand
that it's not the most used case.
Adding a couple of additional functions to a set of already ones just adds
more symbols not always used.
Ideally, I'd see an HTTP module in the future enabled in
request/response-oriented SAPI but that's a different story.
>
> I deliberately didn't call it getRequest (or
> get_request) to not
> confuse people why there isn't also a post_request or
> put_request or
> ... you get the picture)
>
> One additional function in global namespace and then we can use one of
> the request-objects that are already out in the wild. I don't think
> there's a need to invent the wheel again.
>
> The advantage might be that no matter how many calls to
> request() you
> will always get the same result. The Request as it came in.
>
That sounds like a use for a const?!
Just my .50€
Cheers,
Michał Marcin Brzuchalski