Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108782 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 35382 invoked from network); 27 Feb 2020 17:38:02 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 27 Feb 2020 17:38:02 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 184C018050B for ; Thu, 27 Feb 2020 07:55:59 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS29169 217.70.176.0/20 X-Spam-Virus: No X-Envelope-From: Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 27 Feb 2020 07:55:57 -0800 (PST) X-Originating-IP: 107.223.28.39 Received: from samurai.attlocal.net (107-223-28-39.lightspeed.nsvltn.sbcglobal.net [107.223.28.39]) (Authenticated sender: pmjones@pmjones.io) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id A18711BF220; Thu, 27 Feb 2020 15:55:26 +0000 (UTC) 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: Date: Thu, 27 Feb 2020 09:55:25 -0600 Cc: php internals Content-Transfer-Encoding: quoted-printable Message-ID: <012FB9B5-B2F6-4C2D-9F12-5F5BAC508742@pmjones.io> References: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io> <5904137.fSVIMsojiJ@mcmic-probook> <3DDBFBA4-8D3A-46C5-9A10-B093A5E2386B@pmjones.io> <54493258-B52E-442A-A11D-82E1D4C7DE5E@gmail.com> <8264F6CF-AD55-41E2-9F5A-DAE8942E2B79@pmjones.io> <1BF3D29A-04C6-4A82-9216-EAE991A38916@pmjones.io> <10388b3a-3402-a6dc-3837-b03d735edf46@gmail.com> <5ec7b4a7-508b-270b-916f-0504a116196c@gmail.com> <30112AFF-38F9-44D4-9D2F-03A32019764F@pmjones.io> <27F45990-E3AE-4A77-85EC-A2CA1EAC73E4@pmjones.io> To: Rowan Tommins X-Mailer: Apple Mail (2.3608.60.0.2.5) Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2) From: pmjones@pmjones.io ("Paul M. Jones") Hi Rowan, > Why not hope that ReactPHP and others will want to use this object, > precisely because it avoids them having to roll their own = implementations > of things? Like I said earlier: if React ends up wanting to use ext/request, with = its tradeoffs, of course I would think that's great. But if they want to = keep using what they have already, with its own tradeoffs, that's great = too. > If somebody really wanted to use the parser without the rest of the = object, > they could trivially wrap it in a function: >=20 > function parse_multipart_form_data($content) { > $request =3D new ServerRequest([], $content); > return [ 'input' =3D> $request->input, 'uploads' =3D> = $request->uploads ]; > } This is very similar to what I'm saying: to use your phrasing, I opine = it is better to "trivially wrap" the existing PHP functionality as part = of a separate RFC, rather than try to embed it in ServerRequest (exposed = or otherwise). To reiterate what I've said before: this RFC is a relatively = conservative one. The vision around it is to stay pretty close to PHP = as-it-is, and to incorporate those things from the researched = implementations that show up over and over again. I know that does not lead quickly toward (what I surmise is) your vision = of overhauling how PHP presents global state, but an overhaul of that = kind is just not what this RFC aims to do. --=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