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

> On Feb 26, 2020, at 1:55 PM, Rowan Tommins <rowan.collins@gmail.com> wrote: > > On Wed, 26 Feb 2020 at 16:42, Paul M. Jones <pmjones@pmjones.io> wrote: > >> Your presumption is correct! And your point on trying for better names is >> well-taken -- though I think these are "expected" names, based on my >> research into existing implementations. The most-common names are ... >> >> - the word "files" for unparsed or unmodified $_FILES values, leading me >> to think $files is well-understood >> >> - the words "upload(s)", "fileUpload(s)", or >> "uploadedFile(s)" for parsed, >> transformed, or restructured $_FILES values, leading me to think $uploads >> is well-understood >> > > > That's a reasonable justification. Just to check, are there other > implementations that have both of these names side by side, or do most > implementations have one or the other, but using this naming? > > The main confusion I can see is having to remember which two of these is an > error without having to read the docs each time: > > isset( $request->files['attachment']['name'][0] ); > isset( $request->files['attachment'][0]['name'] ); > isset( $request->uploads['attachment']['name'][0] ); > isset( $request->uploads['attachment'][0]['name'] ); Here is an easy way to remember: $request->files is exactly like $_FILES (and if you can't remember that, blame PHP, not the RFC) $request->uploads is therefore new, and since it is new it follows a reasonable collection-list-item structure (as opposed to an unreasonable collection-item-list structure that PHP implemented in $_FILES.) So from those rules: // Don't use, it's the old way of doing things, unless you are just replacing a reference to $_FILES then then it's a non-issue. isset( $request->files['attachment']['name'][0] ); // Don't use, it's the old way of doing things, unless you are just replacing a reference to $_FILES then then it's a non-issue. isset( $request->files['attachment'][0]['name'] ); //Don't use. Not a reasonable collection-list-item structure. Why would "they" create a new API with a parallel array structure?!? isset( $request->uploads['attachment']['name'][0] ); // This one is golden! It's clearly new because of now $_UPLOADS existing, and it follows a reasonable collection-list-item structure isset( $request->uploads['attachment'][0]['name'] ); #jmtcw -Mike