Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100093
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.174 as permitted sender)
Date: Fri, 28 Jul 2017 22:12:10 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <CAESVnVpF53Nn=K-CbVh8NSEqzebpdzZ7WgGsq91TWfo47GbEJw@mail.gmail.com>
References: <CAESVnVpF53Nn=K-CbVh8NSEqzebpdzZ7WgGsq91TWfo47GbEJw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: PHP internals <internals@lists.php.net>
Message-ID: <72B777E0-9E71-4D63-A9D0-20FD62F1A187@gmail.com>
Subject: Re: [PHP-DEV] Changes to SuperGlobals for PHP 8 (was: something about session_start...)
From: rowan.collins@gmail.com (Rowan Collins)

Hi Sara,

>>> On Fri, Jul 28, 2017 at 5:45 PM, Sara Golemon <pollita@php=2Enet>
>wrote:
>>>> ftr; I'd vote in favor of several BC breaking things to do with
>>>> autoglobals, among them:
>>>>
>>>> * Make them objects (though ArrayAccess based for less hostile BC
>>>> breakage)
>>>> * Make most of them read-only (offsetGet(), but no offsetSet)
>>>> * Make $_SESSION[=2E=2E=2E] access produce an error or auto-start the
>session

Yep, this is pretty much what I had in mind when I made that passing remar=
k, but didn't want to derail the thread=2E Now it has its own thread, howev=
er, I'm going to argue against myself and say why I think this is the wrong=
 direction=2E ;)

The obvious downside of changing request vars to read only is the huge bod=
y of code that writes to them=2E This isn't all bad code: as rhsoft points =
out, testing any code that *reads* those vars necessarily requires the harn=
ess to write to them; and a common way to *prevent* reading them is to over=
write them with empty values=2E

More importantly, though, it's papering over the problem, which is that re=
quest information shouldn't be global=2E There are other barriers to a thre=
aded, event-based SAPI becoming core and default, but a scoped request repr=
esentation would be high up the todo list=2E

There was mention a while ago of discussion in the Python community of rep=
lacing WSGI with an even more flexible interface for the HTTP2 era, support=
ing worker and server push models as well as request-response=2E The sugges=
tion was that PHP could learn from or even collaborate on that model=2E Doe=
s anyone know its status?

Obviously, that's a much more ambitious project, but if we're talking 10 y=
ears to phase in a breaking change, it would be good to at least attempt so=
me future-proofing, rather than just adding a few restrictions which were m=
issed 10 years ago, and implicitly extending the lifetime of the concept of=
 global request data=2E

On a slight tangent, I consider $_SERVER to be a broken pile of "we'll jus=
t shove this in here and hope for the best", and I will oppose any attempt =
to convert it into an object which doesn't reorganize its keys to be sane, =
documented, and as cross-platform as the SAPI layer can make it=2E :P

Regards,

--=20
Rowan Collins
[IMSoP]