Changes to SuperGlobals for PHP 8 (was: something about session_start...)

  100087
July 28, 2017 15:11 pollita@php.net (Sara Golemon)
On Fri, Jul 28, 2017 at 11:03 AM, lists@rhsoft.net <lists@rhsoft.net> wrote:
>> On Fri, Jul 28, 2017 at 5:45 PM, 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) >>> * 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
  100088
July 28, 2017 16:21 kalle@php.net (Kalle Sommer Nielsen)
2017-07-28 17:11 GMT+02:00 Sara Golemon <pollita@php.net>:
> 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.
I for one thing it makes a lot of sense to make superglobals read-only, writing to them seems more like a hack anyway and should be avoided -- regards, Kalle Sommer Nielsen kalle@php.net
  100090
July 28, 2017 16:42 lists@rhsoft.net ("lists@rhsoft.net")
Am 28.07.2017 um 18:21 schrieb Kalle Sommer Nielsen:
> 2017-07-28 17:11 GMT+02:00 Sara Golemon <pollita@php.net>: >> 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. > > I for one thing it makes a lot of sense to make superglobals > read-only, writing to them seems more like a hack anyway and should be > avoided
wrong question! the right questions are * are you fored to do so * are you harmed by the possibility and only if you can answer both with "yes" it's worth to cosindr changes breaking a ton of perfect working code
  100091
July 28, 2017 17:54 vchkpw@developersdesk.com (Rick Widmer)
On 7/28/2017 10:42 AM, lists@rhsoft.net wrote:
> > > Am 28.07.2017 um 18:21 schrieb Kalle Sommer Nielsen: >> 2017-07-28 17:11 GMT+02:00 Sara Golemon <pollita@php.net>: >>> 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. >> >> I for one thing it makes a lot of sense to make superglobals >> read-only, writing to them seems more like a hack anyway and should be >> avoided > > wrong question! > > the right questions are > > * are you fored to do so > * are you harmed by the possibility > > and only if you can answer both with "yes" it's worth to cosindr changes > breaking a ton of perfect working code >
What he said. That would break almost everything I've written.
  100113
July 29, 2017 20:17 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> I for one thing it makes a lot of sense to make superglobals > read-only, writing to them seems more like a hack anyway and should be > avoided
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. -- Stas Malyshev smalyshev@gmail.com
  100116
July 29, 2017 23:35 kalle@php.net (Kalle Sommer Nielsen)
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. If its something simple such as your code assumes $_GET['id'] always is available, then either write it to a temp variable. 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. -- regards, Kalle Sommer Nielsen kalle@php.net
  100117
July 30, 2017 00:18 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> 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.
That's what I said - you can always add a layer of indirection. But why? What is so sacred in those variables that writing into them is taboo and writing into intermediate layer is OK?
> If its something simple such as your code assumes $_GET['id'] always > is available, then either write it to a temp variable.
Again, could do it, but why? What is so special in '_GET' that is not in temp variable? Why make me do extra work?
> 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.
Request context is a global state. It is a legit global state - everything within the request is executed in the context of the request. If you put this global state into some kind of intermediate layer instead of _GET, you would have absolutely the same global state issues. You can write your app so that it extracts data from global state into local state and does not depend on it, but this has nothing to do with _GET itself - you could do it very well without changing anything with _GET. Changing _GET does not solve the issues if you use global state, and the issues do not exist if you don't. -- Stas Malyshev smalyshev@gmail.com
  100124
July 30, 2017 18:01 rowan.collins@gmail.com (Rowan Collins)
On 30 July 2017 01:18:56 BST, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>Request context is a global state. It is a legit global state - >everything within the request is executed in the context of the >request.
This is true within the context of the current "shared nothing" design of PHP. There has been talk - and indeed existing implementations - of a more event-based system, where this state would no longer be naturally global in any sense. But as I mentioned before, that ought to lead us to designing a much more radical new representation, rather than just playing around with the current superglobals. Regards, -- Rowan Collins [IMSoP]
  100127
July 30, 2017 19:14 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> This is true within the context of the current "shared nothing" > design of PHP. There has been talk - and indeed existing > implementations - of a more event-based system, where this state > would no longer be naturally global in any sense. But as I
That's fine - but in that design, you should not be using environment that is true global. You should be using something else. As such, there's no reason to mess with superglobals.
> radical new representation, rather than just playing around with the > current superglobals.
And I have no problem with that. As I said, you can always build a layer of indirection that suits your particular design, and many frameworks do just that. But to enable this, the language layer - the bottom layer - should be flexible, and it is such right now. -- Stas Malyshev smalyshev@gmail.com
  100119
July 30, 2017 04:53 lists@rhsoft.net ("lists@rhsoft.net")
Am 30.07.2017 um 01:35 schrieb Kalle Sommer Nielsen:
> 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.
well, you can do that in your code as you like
> If its something simple such as your code assumes $_GET['id'] always > is available, then either write it to a temp variable.
or just leave that decision to the developer
> 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
frankly are you forced to use it? PHP has really more important possible improvements than breaking others code just because you like to see something gone - in my code i write to $_SERVER in a central point to fix the issue that you developers missed to standardize what is available there 15 years ago on differnet operating systems/SAPI's hence my code runs since 15 years ago without spit checks around all over the codebase and now you "like to see that gone"? frankly i like the "what can i do to break others code" attitude of some people go and if you like to break something for a good reason fix inconsistences in the param oders of some database unctions - but better don't because i fear your proposed solution would be "why not remove anything except PDO"
  100121
July 30, 2017 10:35 zeev@zend.com (Zeev Suraski)
> -----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
  100089
July 28, 2017 16:41 pmjones88@gmail.com (Paul Jones)
> On Jul 28, 2017, at 10:11, Sara Golemon <pollita@php.net> wrote: > > 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.
If this kind of big change is being contemplated, I would very much be in favor of decoupling the various combined elements of sessions. In particular, decoupling the auto-reading and auto-sending of cookies from the storage interactions. Also, the "request" extension (and its related RFC) may have some use here, as it attempts to address the readable nature of superglobals. - http://pecl.php.net/package/request - https://wiki.php.net/rfc/request_response -- Paul M. Jones pmjones88@gmail.com http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php
  100092
July 28, 2017 18:29 johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)
On Fr, 2017-07-28 at 11:11 -0400, Sara Golemon wrote:
> I'm sure there will be many strong opinions on this, but let's move > this to a new thread. :D
Language-wise, I think, refactoring that system would be good. I guess a refactoring is a register_globals-like project, which took 10 years from first deprecations to final removal, since many people abuse it and parameter handling is core to PHP. For read-only access we already have an API: filter_input() etc., maybe the interface could be made "nicer." GitHub shows 267,811 hits for that, but only few "real" "productive" cases. From tutorials etc. this doesn't seem to be widely accepted. https://github.com/search?l=PHP&p=1&q=filter_input&type=Code&utf8=%E2%9 C%93 johannes
  100093
July 28, 2017 21:12 rowan.collins@gmail.com (Rowan Collins)
Hi Sara,

>>> On Fri, Jul 28, 2017 at 5:45 PM, 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) >>>> * Make most of them read-only (offsetGet(), but no offsetSet) >>>> * Make $_SESSION[...] access produce an error or auto-start the >session
Yep, this is pretty much what I had in mind when I made that passing remark, but didn't want to derail the thread. Now it has its own thread, however, I'm going to argue against myself and say why I think this is the wrong direction. ;) The obvious downside of changing request vars to read only is the huge body of code that writes to them. This isn't all bad code: as rhsoft points out, testing any code that *reads* those vars necessarily requires the harness to write to them; and a common way to *prevent* reading them is to overwrite them with empty values. More importantly, though, it's papering over the problem, which is that request information shouldn't be global. There are other barriers to a threaded, event-based SAPI becoming core and default, but a scoped request representation would be high up the todo list. There was mention a while ago of discussion in the Python community of replacing WSGI with an even more flexible interface for the HTTP2 era, supporting worker and server push models as well as request-response. The suggestion was that PHP could learn from or even collaborate on that model. Does anyone know its status? Obviously, that's a much more ambitious project, but if we're talking 10 years to phase in a breaking change, it would be good to at least attempt some future-proofing, rather than just adding a few restrictions which were missed 10 years ago, and implicitly extending the lifetime of the concept of global request data. On a slight tangent, I consider $_SERVER to be a broken pile of "we'll just 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. :P Regards, -- Rowan Collins [IMSoP]
  100100
July 29, 2017 14:05 ajf@ajf.me (Andrea Faulds)
Hi Rowan,

Rowan Collins wrote:
> On a slight tangent, I consider $_SERVER to be a broken pile of "we'll just 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. :P
$_SERVER makes sense to me, its content is what the CGI environment variables would be (or are, if you're actually using CGI in 2017). Those are standardised. I don't know if the PHP documentation acknowledges this, though. Its members certainly aren't well-documented… -- Andrea Faulds https://ajf.me/
  100107
July 29, 2017 16:52 rowan.collins@gmail.com (Rowan Collins)
On 29 July 2017 15:05:57 BST, Andrea Faulds <ajf@ajf.me> wrote:
>Hi Rowan, > >Rowan Collins wrote: >> On a slight tangent, I consider $_SERVER to be a broken pile of >"we'll just 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. :P > >$_SERVER makes sense to me, its content is what the CGI environment >variables would be (or are, if you're actually using CGI in 2017). >Those >are standardised.
But what does a standardised CGI variable list have to do with anything when you're running under an Apache module, or one of our two fast-cgi SAPIs, let alone if we ever want event-based or asynchronous SAPIs to be a thing? If you want to know the URL the user requested, you have to know about the subtle differences between half a dozen different variables which will be populated differently, or not at all, depending on your configuration. Some of this is inevitable because there are too many different ways of achieving the same thing, but at least some of it is known by the SAPI, which nonetheless blindly populates $_SERVER with whatever the hosting server provided. And talking of name mangling, CGI mangles the request HTTP headers in its own quirky way, when they should just be a structure of their own separate from this generic environment. That particular quirk can even cause security problems, IIRC. Regards, -- Rowan Collins [IMSoP]
  100114
July 29, 2017 20:22 smalyshev@gmail.com (Stanislav Malyshev)
Hi!


> On a slight tangent, I consider $_SERVER to be a broken pile of > "we'll just 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. :P
You cannot make it cross-platform, as it is specifically made for environment consisting the current platform, making it cross-platform would just force you to create yet another one which contains the bits that didn't fit into "cross-platform". As for sane/documented, documenting every quirk of every system is a herculean task, and we don't have too much control about how (in)sane each OS environment could get. -- Stas Malyshev smalyshev@gmail.com
  100125
July 30, 2017 18:19 rowan.collins@gmail.com (Rowan Collins)
On 29 July 2017 21:22:30 BST, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>> On a slight tangent, I consider $_SERVER to be a broken pile of >> "we'll just 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. :P > >You cannot make it cross-platform, as it is specifically made for >environment consisting the current platform, making it cross-platform >would just force you to create yet another one which contains the bits >that didn't fit into "cross-platform".
I'm fine with having an interface for access to low-level, platform specific details, but that's not how I have mostly seen $_SERVER being used. Mostly, people want specific details, like the requested URL and the HTTP headers sent, all of which should be trivial for SAPIs to provide in a standard, user-friendly format. I wouldn't be surprised if some SAPIs are carefully mangling the data into fake CGI format, only for userland code to unmangle it for actual use. My point was that if we were considering a compatibility break anyway, we should look at separating out those common use cases into something higher level. Having done that, we could even allow the low-level "raw server vars" (not under the name $_SERVER) to drift even further apart, rather than sticking to CGI rules from 20+ years ago. Regards, -- Rowan Collins [IMSoP]
  100128
July 30, 2017 19:21 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> My point was that if we were considering a compatibility break > anyway, we should look at separating out those common use cases into > something higher level.
I'm completely in agreement with you here, except for "compatibility break" part. The good news is that you do not need any compatibility breaks! If you want to create API that allows easy standardized access to the common denominator of web requests - and I do not disagree it would be a good thing! - you do not need to change _SERVER. In fact, there's no reason to change it as if you turn _SERVER into this layer, this would only lead to creating _REAL_SERVER containing what _SERVER used to. Instead, we could just create this layer - either as $_SAPI, or as function collection, or as object if people want it that way - does not matter, really - and let it live by itself, not encumbered by any concerns about BC and not hurting any existing apps. I do not see any downside to this approach, do you?
> Having done that, we could even allow the low-level "raw server vars" > (not under the name $_SERVER) to drift even further
Why not under the name _SERVER? -- Stas Malyshev smalyshev@gmail.com
  100131
July 30, 2017 22:54 rowan.collins@gmail.com (Rowan Collins)
On 30 July 2017 20:21:01 BST, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>Hi! > >> My point was that if we were considering a compatibility break >> anyway, we should look at separating out those common use cases into >> something higher level. > >I'm completely in agreement with you here, except for "compatibility >break" part. The good news is that you do not need any compatibility >breaks! If you want to create API that allows easy standardized access >to the common denominator of web requests - and I do not disagree it >would be a good thing! - you do not need to change _SERVER.
A good point. Of course, "if" doesn't have to be symmetrical, so perhaps I should say that if we plan to break compatibility, we should definitely do this; if we don't plan to, we should maybe do it anyway.
>> Having done that, we could even allow the low-level "raw server vars" >> (not under the name $_SERVER) to drift even further > >Why not under the name _SERVER?
In general, I always think that when splitting something, you should rename both parts, not keep one. Code using the retained name will continue to partly work but have odd bugs, rather than completely failing until someone reviews which replacement is appropriate. But in reality, you might want to keep $_SERVER around for compatibility anyway, so there'd be no point having 3 different versions of the same thing. The only advantage of a new name at that point would be if we decided to get rid of the shared nothing, global request state model. Regards, -- Rowan Collins [IMSoP]
  100095
July 29, 2017 06:47 thruska@cubiclesoft.com (Thomas Hruska)
On Fri, Jul 28, 2017 at 11:03 AM, lists@rhsoft.net <lists@rhsoft.net> wrote:
> 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 :-)
Are you advocating for read-only or leaving them read-write? I can't tell. Every language feature in every language can be abused. Having sufficient documentation helps avoid unwanted abuse. As a brief demonstration of how that plays out, a quick search on the website turned up: http://us3.php.net/manual/en/reserved.variables.request.php There isn't an example usage pattern there nor any restrictions/recommendations on use and the top comment has 97 upvotes. The first thing that person's code does is freely set new values in multiple superglobals without sufficient explanation that doing so is a bad idea. Therefore, drive-by PHP users can derive that it must be okay to store general-purpose information into a superglobal. "This must be the right way to do things since it has over 10 times as many upvotes as the next comment on the page." While I'm for read-write superglobals, I will, of course, live with whatever is decided upon and adapt accordingly. Making some documentation adjustments seems like a simpler thing to do than a BC break. -- Thomas Hruska CubicleSoft President I've got great, time saving software that you will find useful. http://cubiclesoft.com/ And once you find my software useful: http://cubiclesoft.com/donate/
  100099
July 29, 2017 13:04 lists@rhsoft.net ("lists@rhsoft.net")
Am 29.07.2017 um 08:47 schrieb Thomas Hruska:
> On Fri, Jul 28, 2017 at 11:03 AM, lists@rhsoft.net <lists@rhsoft.net> > wrote: >> 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 :-) > > Are you advocating for read-only or leaving them read-write? I can't tell
how comes? -------- Weitergeleitete Nachricht -------- Betreff: Re: [PHP-DEV] Changes to SuperGlobals for PHP 8 Datum: Fri, 28 Jul 2017 18:42:16 +0200 Von: lists@rhsoft.net <lists@rhsoft.net> An: internals@lists.php.net Am 28.07.2017 um 18:21 schrieb Kalle Sommer Nielsen: > I for one thing it makes a lot of sense to make superglobals > read-only, writing to them seems more like a hack anyway and should be > avoided wrong question! the right questions are * are you fored to do so * are you harmed by the possibility and only if you can answer both with "yes" it's worth to consider changes breaking a ton of perfect working code -------- Weitergeleitete Nachricht -------- Betreff: Re: [PHP-DEV] session_start() should not reset $_SESSIOn if it's not empty Datum: Fri, 28 Jul 2017 15:37:10 +0200 Von: lists@rhsoft.net <lists@rhsoft.net> An: internals@lists.php.net Am 28.07.2017 um 14:48 schrieb Rowan Collins: > On 27 July 2017 18:03:23 BST, "lists@rhsoft.net" <lists@rhsoft.net> wrote: >> if that could work in the way that session_start() keeps the current >> state of $_SESSION if not empty it would be possible to put the >> APCU-Read and if exit($apcu_content); before session_start() which >> would >> gain another 30% performance > > I think that behaviour would confuse more people than it would help. If anything, it should be an error to access $_ SESSION if no session is currently open - if there is no session, the array has no meaning. (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 including autotests and code-coverage tools because it is legit to as example fill $_SERVER['SERVER_NAME'] with specific informations to define a straight behavior when running in cli-test-mode instead wrap every basic thing in function calls - at the curretn state a core-cms cache-hit has a total of 32 funtion calls including PHP internal ones hence that 3 bugreport are becoming a MAJOR PROBLEM because the system itself is so fast that under load after a short time you get problems with dattabase connections and with persistent connections because of the third one after the load is gone any strict-typed application jsut breaks horrible https://bugs.php.net/bug.php?id=74971 https://bugs.php.net/bug.php?id=74970 https://bugs.php.net/bug.php?id=74967
  100097
July 29, 2017 10:27 danack@basereality.com (Dan Ackroyd)
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
  100102
July 29, 2017 14:14 pmjones88@gmail.com (Paul Jones)
> On Jul 29, 2017, at 05:27, Dan Ackroyd <danack@basereality.com> wrote: > > 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.
Having done it several times before in userland helps. Presenting the superglobals as read-only properties does the trick for the `request` extension; it's even simpler than using methods. -- Paul M. Jones pmjones88@gmail.com http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php
  100101
July 29, 2017 14:08 ajf@ajf.me (Andrea Faulds)
Hi Sara,

I'd just like to add that if we were going to make BC-breaking changes 
to superglobals in PHP 8, we might as well also get rid of the name 
mangling on keys for $_GET, $_POST and $_REQUEST at the same time 
("foo.x" becomes "foo_x" etc, because we used to have register_globals 
and needed clean variable names).

Thanks for bringing this up!
-- 
Andrea Faulds
https://ajf.me/
  100104
July 29, 2017 14:29 pollita@php.net (Sara Golemon)
On Sat, Jul 29, 2017 at 10:08 AM, Andrea Faulds <ajf@ajf.me> wrote:
> I'd just like to add that if we were going to make BC-breaking changes to > superglobals in PHP 8, we might as well also get rid of the name mangling on > keys for $_GET, $_POST and $_REQUEST at the same time ("foo.x" becomes > "foo_x" etc, because we used to have register_globals and needed clean > variable names). > Excellent point. I always forget this is a thing we do and it needs
to die. Even if we leave everything else aboue the super globals alone, this one thing should die in PHP 8. -Sara
  100109
July 29, 2017 16:58 ajf@ajf.me (Andrea Faulds)
Sara Golemon wrote:
> On Sat, Jul 29, 2017 at 10:08 AM, Andrea Faulds <ajf@ajf.me> wrote: >> I'd just like to add that if we were going to make BC-breaking changes to >> superglobals in PHP 8, we might as well also get rid of the name mangling on >> keys for $_GET, $_POST and $_REQUEST at the same time ("foo.x" becomes >> "foo_x" etc, because we used to have register_globals and needed clean >> variable names). >> > Excellent point. I always forget this is a thing we do and it needs > to die. Even if we leave everything else aboue the super globals > alone, this one thing should die in PHP 8.
Come to think of it, can we fix $_FILES while we're at it? :p -- Andrea Faulds https://ajf.me/
  100110
July 29, 2017 17:01 pmjones88@gmail.com (Paul Jones)
> On Jul 29, 2017, at 11:58, Andrea Faulds <ajf@ajf.me> wrote: > > Come to think of it, can we fix $_FILES while we're at it? :p
Not to be a broken record here, but this is something the `request` extension does as well. In other words, a starting point for a lot of this work already exists. -- Paul M. Jones pmjones88@gmail.com http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php
  100122
July 30, 2017 10:36 zeev@zend.com (Zeev Suraski)
> -----Original Message----- > From: php@golemon.com [mailto:php@golemon.com] On Behalf Of Sara > Golemon > Sent: Saturday, July 29, 2017 5:29 PM > To: Andrea Faulds <ajf@ajf.me> > Cc: PHP internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] Re: Changes to SuperGlobals for PHP 8 (was: something > about session_start...) > > On Sat, Jul 29, 2017 at 10:08 AM, Andrea Faulds <ajf@ajf.me> wrote: > > I'd just like to add that if we were going to make BC-breaking changes > > to superglobals in PHP 8, we might as well also get rid of the name > > mangling on keys for $_GET, $_POST and $_REQUEST at the same time > > ("foo.x" becomes "foo_x" etc, because we used to have register_globals > > and needed clean variable names). > > > Excellent point. I always forget this is a thing we do and it needs to die. Even if > we leave everything else aboue the super globals alone, this one thing should > die in PHP 8.
Agreed. Zeev
  100115
July 29, 2017 20:25 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> I'd just like to add that if we were going to make BC-breaking changes > to superglobals in PHP 8, we might as well also get rid of the name > mangling on keys for $_GET, $_POST and $_REQUEST at the same time
That's a good point. We definitely should get rid of this one, it adds absolutely nothing now. It might expose some security issues though in bad scripts that rely on mangling for safety while recomposing URLs (which of course they shouldn't but... sigh...) -- Stas Malyshev smalyshev@gmail.com