Re: Changes to SuperGlobals for PHP 8 (was: something about session_start...)
| From: | Dan Ackroyd | Date: | Sat, 29 Jul 2017 10:27:15 +0000 |
| Subject: | Re: Changes to SuperGlobals for PHP 8 (was: something about session_start...) | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-100097@lists.php.net to get a copy of this message | ||
On 28 July 2017 at 16:11, Sara Golemon <pollita@php.net> 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)
Why objects?
Although these are kind of just about related things they don't
require being in a class/interface.
Designing classes/interfaces to be correct the first time is a really
difficult thing to do, and then maintaining classes/interfaces is hard
as any change to a method is a BC break.
I feel pretty strongly that 'just' using a set of function to read the
data would be the correct thing to do as:
i) they are easier to maintain.
ii) They allow people to composite them into objects easily.
iii) They're simpler to use in code.
> I've seen too many codebases abuse GPCER vars as a generic storage
> Restricting their mutability would be a win.
Or we could just leave the global mutable variables alone, and just
introduce the new set of functions to get the original unmodified
data, which would be inherently read-only.
That allows everyone who wants to move away from mutable state to do
so, leaves current applications working, and we can have the
lovely-and-not-at-all-depressing "WHY ARE YOU TERRIBLE PEOPLE BREAKING
WORKING CODE!!1!" conversation as a separate discussion; one that
doesn't get in the way of allowing people who'd prefer to move forward
with saner global state.
cheers
Dan