On Fri, Jul 28, 2017 at 11:03 AM, li...@rhsoft.net <li...@rhsoft.net> wrote:
>> On Fri, Jul 28, 2017 at 5:45 PM, Sara Golemon <poll...@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)
>>> * 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
>>>
>>
>> Yes, please!
>
>
> raise a warning when write to $_SESSION without a session_start()
>
> make a implicit autostart - *for sure not* this would only produce hidden
> errors or later warnings when you rely on session params and introduce more
> problems that it solves because clients don't like the same cookies ith
> different params
>
> make POST/GET/SERVER readonly - only when you refactor a 250000 line code
> base as well as deplyed code which relies on the framework did the right
> thing with them previously :-)
>
>
I'm sure there will be many strong opinions on this, but let's move
this to a new thread. :D

1. This would be an 8.0 change as it does represent a significant BC change.
2. We can discuss the possibility of INI options or other mitigation
strategies for misbehaving code bases (and they do exist).
3. I'm definitely not decided on what I'd like from default session
behavior. An error isn't out of the question, for sure.

-Sara

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to