On Fri, Jul 28, 2017 at 10:11 AM, Rowan Collins <rowan.coll...@gmail.com> wrote: > On 28 July 2017 14:37:10 BST, "li...@rhsoft.net" <li...@rhsoft.net> wrote: >>(Arguably, all the other superglobals should be read only for the same >>reason, but that would be a huge break now.) >> >>make them readonly would break my whole codebase > > Yes, I only meant that as an absolutely hypothetical "if I had a time machine > and could design it a different way...", I realise it would break everything > to change it now. > > 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[...] access produce an error or auto-start the session I've seen too many codebases abuse GPCER vars as a generic storage location because "globals are bad, but this is good because it doesn't include the word global". As a performance issue, the runtime has to assume autoglobals are inherently volatile and could change on a whim at any moment (much like $http_response_headers). Restricting their mutability would be a win. The request globals could probably also be optimized fairly significantly. If anyone agrees, I'm willing to RFC it. If not, I'll continue living with it. :D -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
