Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100128
Return-Path: <smalyshev@gmail.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 43730 invoked from network); 30 Jul 2017 19:21:08 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
by localhost with SMTP; 30 Jul 2017 19:21:08 -0000
Authentication-Results: pb1.pair.com header.from=smalyshev@gmail.com; sender-id=pass
Authentication-Results: pb1.pair.com smtp.mail=smalyshev@gmail.com; spf=pass; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.180 as permitted sender)
X-PHP-List-Original-Sender: smalyshev@gmail.com
X-Host-Fingerprint: 209.85.161.180 mail-yw0-f180.google.com
Received: from [209.85.161.180] ([209.85.161.180:33818] helo=mail-yw0-f180.google.com)
by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
id 5D/27-07025-2A13E795 for <internals@lists.php.net>; Sun, 30 Jul 2017 15:21:08 -0400
Received: by mail-yw0-f180.google.com with SMTP id s143so13912731ywg.1
for <internals@lists.php.net>; Sun, 30 Jul 2017 12:21:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20161025;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to:content-language:content-transfer-encoding;
bh=hFdYw74UFWsQh7NS7UJr6nLyLvdvd7vd59KYX5uIAnA=;
b=I91Ng8dOOVR1w7I8+DvrygDwvbnHYwj/YqQL1sr6CEx62n0txV8+2L3tiT18mwmJis
fqkGN3+5vnuS1WR40ScV96EomDB2PbRdvimbtJjEzIpPdXEmjQqFb5x9fULufJTwkMG1
QbQatGpa3X4xqQ+MNtqC13sl4Dh7d8DVxqDKarLiCGYl3/U33R4CZ4+xF6vZ6ivD/nrM
HE4G7ZZxFMwXqwM+K/hA4chDPbB5kQhOqHJpR2366POtv/5A63V3Vy/S4OsUYYJbm/6M
Z0K5rH8ZiLXTGwkFMJ/jbICRaw7Cpndq7F8uwtSlYau9ZaYZbokzC0kncYcKawYMoOXi
ZZNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:references:from:message-id:date
:user-agent:mime-version:in-reply-to:content-language
:content-transfer-encoding;
bh=hFdYw74UFWsQh7NS7UJr6nLyLvdvd7vd59KYX5uIAnA=;
b=d1sWP0OAV4pSk79bw97VjSzw5pQLEp1fXgvcB1NXt2kOFE2rs1NT6kZQkwG5MhB6c1
vEXo+UG0L2WZMIxUswZIKiX+mFdfzu4NE317u5EJGNm6HeU9vzl7WHOQIuTB9nlUJx8n
XHE7GMrmlBMycjxuJwFGjDxqkM3M7NckXUoduInurKd/8kQ6hXX00k5i5jzfKMT4PbKZ
yG5Mxlrzd3k6n4KNh0KggK/pxfjMFY4ukSMnYxPW8DzH6Pjg+W4Eqetq2eg5e5qCZAkk
UW4xoxiQfbClegEM5jllXhVCAuRcdsoTy5qCTGnAvPWBCRI8XfzlGXIRmaMhh3mXYZcT
SDEw==
X-Gm-Message-State: AIVw111lO9Qx/Qq8ktEN7UPPJH8QtbK0RcykXlXCSVpyH+Bg6+jv6AnV
iviibTmAoW4YtYmKP00=
X-Received: by 10.37.220.135 with SMTP id y129mr2494273ybe.246.1501442463609;
Sun, 30 Jul 2017 12:21:03 -0700 (PDT)
Received: from ?IPv6:2602:306:ce9c:e680:b5a6:5d11:6172:efb? ([2602:306:ce9c:e680:b5a6:5d11:6172:efb])
by smtp.gmail.com with ESMTPSA id j11sm9723809ywj.96.2017.07.30.12.21.02
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sun, 30 Jul 2017 12:21:03 -0700 (PDT)
To: Rowan Collins <rowan.collins@gmail.com>,
PHP internals <internals@lists.php.net>
References: <CAESVnVpF53Nn=K-CbVh8NSEqzebpdzZ7WgGsq91TWfo47GbEJw@mail.gmail.com>
<72B777E0-9E71-4D63-A9D0-20FD62F1A187@gmail.com>
<d5b836f9-3e2e-a568-0dec-1e8cb1ac290b@gmail.com>
<231D3A47-F8BE-47C8-B1BB-B6F320BED367@gmail.com>
Message-ID: <6c5dd09b-904b-b518-bd89-50cd28cbeaae@gmail.com>
Date: Sun, 30 Jul 2017 12:21:01 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0)
Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <231D3A47-F8BE-47C8-B1BB-B6F320BED367@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Changes to SuperGlobals for PHP 8
From: smalyshev@gmail.com (Stanislav Malyshev)
Hi!
> My point was that if we were considering a compatibility break
> anyway, we should look at separating out those common use cases into
> something higher level.
I'm completely in agreement with you here, except for "compatibility
break" part. The good news is that you do not need any compatibility
breaks! If you want to create API that allows easy standardized access
to the common denominator of web requests - and I do not disagree it
would be a good thing! - you do not need to change _SERVER. In fact,
there's no reason to change it as if you turn _SERVER into this layer,
this would only lead to creating _REAL_SERVER containing what _SERVER
used to.
Instead, we could just create this layer - either as $_SAPI, or as
function collection, or as object if people want it that way - does not
matter, really - and let it live by itself, not encumbered by any
concerns about BC and not hurting any existing apps. I do not see any
downside to this approach, do you?
> Having done that, we could even allow the low-level "raw server vars"
> (not under the name $_SERVER) to drift even further
Why not under the name _SERVER?
--
Stas Malyshev
smalyshev@gmail.com