Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108613 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 48232 invoked from network); 16 Feb 2020 03:22:22 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 16 Feb 2020 03:22:22 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 7AD9D18050A for ; Sat, 15 Feb 2020 17:37:24 -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.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 15 Feb 2020 17:37:21 -0800 (PST) Received: by mail-wr1-f41.google.com with SMTP id k11so15424100wrd.9 for ; Sat, 15 Feb 2020 17:37:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:user-agent:in-reply-to:references:mime-version :content-transfer-encoding:subject:to:from:message-id; bh=h2dB38CuFFnF7MQTERCk8AP56Sh6tudUBbR7BSpvZSU=; b=ZRFBY9MZItpgfIn5iXkeZc/p2djEuCIf6qhH46c/L/tQLDuxP6uRFE3W89IwSn6Z4j NP020+XsGAXuWs/hyJlCnefpSSFmzvZ9CH6JH/Jb/1LZX56SCvfOOElQ9Mv0Qzil8BjX lMSyUB06Rh12z55vcCTMaTUdJx1Tr8NDFad9O16/gn5UM2bJ6r+5poWwF/yfyIU6M0DW Cb6EGH33tGEmLFlw24cXujAz146Xgg8czNuTmEN/d06ymM89YmnePuuNSIBMABI6JH3e rpDHQY91BPFw958MoQQCe0a51VYZhGpKYzOEXs8q6VuNSrsrS9KNUNhgTPP4sRK7pf1D Y5YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:subject:to:from:message-id; bh=h2dB38CuFFnF7MQTERCk8AP56Sh6tudUBbR7BSpvZSU=; b=jTVKGQcD1TDeKLbHmT5koMQrOHCLOyeg21G3OvX2kr7uZPhumRlNp3U+qHxWkug8yh 7ZInAs+RHeTMQnPRjS3bSj4HUXsyWUEtzbirg1nsl2ewVi10Oclll1Rv99GIn8gdChBH XXhlI/e3/onFXlFf5rADDuY6W2f4rYMlD2PrNCo/tqaMqgk/DOra8icxfgOMlwPgNtYv OwB3C2YBT6D2Do0/xGFKf/f7kEZOKLQ7yE+YGBHOVTQlMzsZlZq0nkVN13ETRnWTo8zj RYNk/gJRJaC5oykoni5kXwX7okvxazwcMuFZ33OWZnszWMwZGPxKJq7mtr+8EFVyueLe t7oQ== X-Gm-Message-State: APjAAAXNGKKDSyxcB027iBLC5+OXHPFE2B28d4RrJGRT7LtgZlsBIG5m P5988WBtqOz213uMhl4X9cgs2Lri X-Google-Smtp-Source: APXvYqxhibe24MSiGT9iGDX0Z49S/nhdvkdYqh8YkC/zD6mx31OsLaP+iKDGASV8E+9NOwsxM68Pgw== X-Received: by 2002:a5d:538e:: with SMTP id d14mr13124548wrv.358.1581817038189; Sat, 15 Feb 2020 17:37:18 -0800 (PST) Received: from [192.168.0.12] (cpc84253-brig22-2-0-cust114.3-3.cable.virginm.net. [81.108.141.115]) by smtp.gmail.com with ESMTPSA id f11sm13611243wml.3.2020.02.15.17.37.16 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 15 Feb 2020 17:37:17 -0800 (PST) Date: Sun, 16 Feb 2020 01:37:15 +0000 User-Agent: K-9 Mail for Android In-Reply-To: <3DDBFBA4-8D3A-46C5-9A10-B093A5E2386B@pmjones.io> References: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io> <5904137.fSVIMsojiJ@mcmic-probook> <3DDBFBA4-8D3A-46C5-9A10-B093A5E2386B@pmjones.io> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----97136DW9UHUAQ6LIBJ3BS4EGYHXMLF" Content-Transfer-Encoding: 7bit To: internals@lists.php.net Message-ID: <54493258-B52E-442A-A11D-82E1D4C7DE5E@gmail.com> Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2) From: rowan.collins@gmail.com (Rowan Tommins) ------97136DW9UHUAQ6LIBJ3BS4EGYHXMLF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 15 February 2020 20:10:30 GMT+00:00, "Paul M=2E Jones" wrote: >Hi all, > >> On Feb 15, 2020, at 02:01, Larry Garfield >wrote: >>=20 >> =2E=2E=2E is this proposal intended to supplant HttpFoundation and PSR-= 7 >=2E=2E=2E ? > >This is question is answered in the RFC introduction You've cut Larry's question in half there, and in doing so made it seem li= ke a repeat, when it is not=2E The second half of the sentence is this: > =2E=2E=2Eor to become a common underpinning that both of them wrap, or t= o be a third cohabitating implementation in the ecosystem? I haven't seen you answer that part yet: do you expect existing userland l= ibraries to migrate from wrapping $_GET etc to using these built-in wrapper= s=2E If so, what benefit does it bring those libraries? If not, who is its = intended audience? You said previously: > PDO did not (to my knowledge) "add capabilities which cannot exist in us= erland or cannot exist in a reasonably performant way"=2E I think this is a misjudgement, and a relevant one=2E PDO didn't take func= tionality that existed purely in userland and migrate it to an extension; i= t took functionality that was scattered across a dozen different vendor-spe= cific extensions with different naming and calling conventions, and central= ised it into one more-or-less consistent interface=2E In doing so, it made = (or at least tried to make) life easier both for database vendors, who can = provide a PDO driver and fit into the ecosystem, and library developers, wh= o can use PDO as a base and have less vendor-specific code=2E Your other examples - date, phar, and session - took common problems that = were possible to solve in userland but tricky to solve well, and provided a= standard out-of-the-box implementation=2E We already have a unified out-of-the-box implementation for the problem "g= et data out of HTTP request", in the form of superglobals, so neither compa= rison seems apt=2E A better comparison might be to features which have been reimplemented mul= tiple times, to fix fundamental problems=2E A recent example is __serialize= , but interestingly $_GET et al are themselves the third implementation of = the feature, after "register globals" and the $HTTP_* arrays=2E As far as I can see, the RFC mentions two things it fixes about the curren= t implementation: - The current implementation is not OO=2E That's not really surprising, si= nce PHP is not a purely OO language, and treats OO as a matter of style - t= o the extent of providing hybrid object-procedural APIs like date and mysql= i=2E - The current implementation is based on global state=2E This is definitel= y something that would be good to fix, but you can do almost as much in tha= t direction as the RFC by writing "$get=3D$_GET; unset($_GET);" The hard pr= oblem is that the entry point for a request is in global scope, not a main(= ) or handleRequest() function=2E Introducing these objects as part of a new= calling convention for PHP scripts would definitely add value, and make th= em a true replacement for the superglobals, but that would be a very differ= ent RFC=2E However well designed this extension is within itself, I think it needs a = stronger description of who should use it and why=2E Regards, --=20 Rowan Tommins [IMSoP] ------97136DW9UHUAQ6LIBJ3BS4EGYHXMLF--