Hi Paul,
I left this thread to settle a bit, because I felt we were going round
in circles a bit. I think there's some fundamental differences in
outlook that no amount of discussion is going to resolve, so I've
trimmed this reply to the more specific points.
On 20/02/2020 14:56, Paul M. Jones wrote:
Aha! If nothing else, then, this conversation has revealed a
documentation flaw: specifically, my failure to document the
ServerRequest $url property. That failure is now remedied:
<https://github.com/pmjones/ext-request#the-url-array>
Aha indeed! When I was talking about "selling it to me", this is exactly
the kind of thing I was looking for. This kind of functionality is much
more interesting to me than copying half a dozen arrays from constructor
parameters into read-only properties.
Which is the purpose of the documentation; it describes the differences between
$files and $uploads.
That's no reason not to *try* for descriptive names, though. I presume
the idea is that one array is expected to be more useful for new code,
and the other is mostly there for compatibility with old code? If so,
perhaps the names could reflect that somehow.
Incidentally, the current documentation doesn't describe the differences
particularly well, just saying one is "more like $_POST". Some details
of the structure, or examples comparing the two arrays, would be useful.
I was actually thinking of the opposite: given a request body which didn't come
from global state, but which contains data in multipart/form-data format,
extract the key-value pairs and attached files.
Is that something PHP "itself" already does? If not, I have to consider it
out-of-scope for this RFC.
a) Yes: Every time you submit a form as multipart/form-data, PHP parses
it into the global state. If this object is aiming to abstract away from
global state, then having a non-global-state parser for that seems
consistent.
b) No: There is no function which currently takes a string and returns
an array for this scenario. However, that's true of other features you
have included, such as parsing accept headers, or even extracting just
HTTP headers from a copy of the $_SERVER array.
Your point on global state is well-taken; I will try to remember in future to phrase it
as "global *mutable* state." (AFAICT, php://input is not mutable, though as you
correctly point out, it is global.)
This distinction seems unnecessary. Once created, the object avoids
global state because it is self-contained, and the fact that it's
read-only is a separate attribute. We're really just talking about ways
to construct that self-contained state, and "everything from global
state" or "nothing from global state" seem like more natural options
than "one thing from global state, everything else not".
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
