Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108778
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <CALKiJKqenOLuUFECKVNPu3ng70q+PGroocWZ7wN1z555Cq-3Mg@mail.gmail.com>
Date: Wed, 26 Feb 2020 16:46:18 -0500
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <04754166-7BB1-41B9-BE9A-72DC6D0FE25B@newclarity.net>
References: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io>
 <CANUQDCiP31aEqULqeGpN66ESHarKxWuXgQt_CqWeCLZc+1L-fA@mail.gmail.com>
 <5904137.fSVIMsojiJ@mcmic-probook>
 <CDBA02D0-07E1-4723-947C-22B403E650C0@pmjones.io>
 <CA+hqhpcOqCqXuOh3bWavJ+pZ5VVhekUO9LkKgd9c+b98VVnZSA@mail.gmail.com>
 <CAG9XoMRm2Nqjg3UbCc5=1_8m2W7qf8QRoSVk6d_qENJCKE1=9A@mail.gmail.com>
 <fcf43463-f9f7-4235-a84b-658074772ed7@www.fastmail.com>
 <3DDBFBA4-8D3A-46C5-9A10-B093A5E2386B@pmjones.io>
 <54493258-B52E-442A-A11D-82E1D4C7DE5E@gmail.com>
 <8264F6CF-AD55-41E2-9F5A-DAE8942E2B79@pmjones.io>
 <f58eea0a-6d71-be57-c0b8-abc4321cdb38@gmail.com>
 <1BF3D29A-04C6-4A82-9216-EAE991A38916@pmjones.io>
 <10388b3a-3402-a6dc-3837-b03d735edf46@gmail.com>
 <CE336F26-F119-49E6-BD7E-43B47B7F4463@pmjones.io>
 <5ec7b4a7-508b-270b-916f-0504a116196c@gmail.com>
 <30112AFF-38F9-44D4-9D2F-03A32019764F@pmjones.io>
 <CALKiJKqenOLuUFECKVNPu3ng70q+PGroocWZ7wN1z555Cq-3Mg@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
From: mike@newclarity.net (Mike Schinkel)

> On Feb 26, 2020, at 1:55 PM, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>=20
> On Wed, 26 Feb 2020 at 16:42, Paul M. Jones <pmjones@pmjones.io> =
wrote:
>=20
>> 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 ...
>>=20
>> - the word "files" for unparsed or unmodified $_FILES values, leading =
me
>> to think $files is well-understood
>>=20
>> - the words "upload(s)", "fileUpload(s)", or "uploadedFile(s)" for =
parsed,
>> transformed, or restructured $_FILES values, leading me to think =
$uploads
>> is well-understood
>>=20
>=20
>=20
> 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?
>=20
> 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:
>=20
> 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] );	=09

// 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=