Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108776
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
In-Reply-To: <CALKiJKqenOLuUFECKVNPu3ng70q+PGroocWZ7wN1z555Cq-3Mg@mail.gmail.com>
Date: Wed, 26 Feb 2020 13:57:49 -0600
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <A24820E4-55B5-4F50-932B-2D9A92E8C70F@pmjones.io>
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: pmjones@pmjones.io ("Paul M. Jones")

Hi Rowan,

> On Feb 26, 2020, at 12:55, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>=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?

My recollection is that they have one or the other, but none with both =
side-by-side. (A very few have neither.)


> 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'] );

/me nods

While I too have imagined that, my impression has been that consumers of =
1.x use $files unless & until they change their systems to use $uploads, =
at which point they switch over entirely to $uploads.  Given that, my =
concerns (such as they may have been) are soothed.


> If getUploads was a method, it could take a similar behaviour switch -
> GROUP_BY_ITEM vs GROUP_BY_ATTRIBUTE or similar. For a property, that =
would
> have to be part of the name, like $uploadsByItem and =
$uploadsByAttribute,
> which are a bit ugly.
>=20
> Alternatively, you could lean more heavily on the legacy aspect, and =
have
> $uploads and $uploadsLegacyFormat or something like that.

Noted.

Are there any others here who feel that the names $files and $uploads =
are "too confusing" (for whatever values of "confusing" you find =
appropriate) ?


> Again, any mention of JSON or XML is drifting away from what I'm =
asking
> for.

Ah, my bad then.


> What I'm asking for (or rather, suggesting would be a useful and
> consistent addition) is a way to do *exactly what PHP does right now*, =
but
> based on a given input string, rather than the initial request.

I'm sorry, I'm still having trouble seeing what you're getting at. Do =
you mean something like this in the ServerRequest constructor?

    public function __construct(array $globals, ?string $content =3D =
null)
    {
        if (
            ($globals['_POST'] ?? null) =3D=3D=3D null
            &&
            strtolower($globals['_SERVER']['CONTENT_TYPE']) =3D=3D=3D =
'application/x-www-form-urlencoded'
        ) {
            if ($content =3D=3D=3D null) {
                $content =3D file_get_contents('php://input');
            }
            $globals['_POST'] =3D [];
            parse_str($content, $globals['_POST']);
        }

        // ...
    }

If so, it seems unnecessary for the goals of this RFC, even overkill.

If not, then I await correction.


> To play devil's advocate, does the [$content] property belong in the =
object at all? If it doesn't interact with any of the other properties =
(e.g. populating $post and $uploads based on form data), could "better =
syntax for getting raw request for global state" be a separate feature. =
Then again, maybe the ability to over-ride it in the constructor is =
enough to make it useful.

I continue to think it does belong there. Often enough, API developers =
will read php://input to decode JSON or XML they find there, so having =
it easily-available as $request->content is appealing.  To boot, the =
other content-related headers are present, so might as well have the =
content itself there too. And as you note, it's easy enough to pass in =
custom $content via the constructor, e.g. for testing.

* * *

I feel that if these are the discussion points, then we are close to =
exhausting the topic (even if we do not agree on everything). Thank you =
for your diligence and attention to detail!


--=20
Paul M. Jones
pmjones@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