RE: [PHP-DEV] Changes to SuperGlobals for PHP 8 (was: something about session_start...)

> -----Original Message----- > From: kalle.php@gmail.com [mailto:kalle.php@gmail.com] On Behalf Of Kalle > Sommer Nielsen > Sent: Sunday, July 30, 2017 2:36 AM > To: Stanislav Malyshev <smalyshev@gmail.com> > Cc: Sara Golemon <pollita@php.net>; PHP internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] Changes to SuperGlobals for PHP 8 (was: something > about session_start...) > > Hi > > 2017-07-29 22:17 GMT+02:00 Stanislav Malyshev <smalyshev@gmail.com>: > > I've seen scenarios where it is very useful. Sure, you can always > > build another layer of indirection and solve it this way, but it's > > just making people do more work for no reason. I don't see any problem that > would solve. > > Sure it seems useful, but I see it more as a hack if you are just writing to > superglobals anyway, if you need to change something you should do that with > your own logic instead. So we agree that it at least seems useful, why do you see it as a hack? What real downsides does it have, that are so overwhelming as to require a change to this behavior that's been with us for countless years and is most likely deeply engrained into many applications? > I know many applications nowadays are not written with an excess amount of > globals everywhere, but writing to a global without explicitly declaring you > want to, can cause some hard to debug cases if one function modifies a global > and another assumes an unmodified value. I'd like to see that gone. I don't recall ever bumping into users complain about this. Do we have examples where this behavior caused a real world bug or security issue? To me, if you don't want to write into super globals, that's entirely your right - and you can enforce that in your organization via a coding standard. IMHO, there's no need to change the language (in a far reaching way) to force you to do that. Zeev