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. :DYes, 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 paramsmake 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
- This would be an 8.0 change as it does represent a significant BC change.
- We can discuss the possibility of INI options or other mitigation
strategies for misbehaving code bases (and they do exist). - 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
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
- This would be an 8.0 change as it does represent a significant BC change.
- We can discuss the possibility of INI options or other mitigation
strategies for misbehaving code bases (and they do exist).- 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
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
- This would be an 8.0 change as it does represent a significant BC change.
- We can discuss the possibility of INI options or other mitigation
strategies for misbehaving code bases (and they do exist).- 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
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
- This would be an 8.0 change as it does represent a significant BC
change.- We can discuss the possibility of INI options or other mitigation
strategies for misbehaving code bases (and they do exist).- 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
avoidedwrong 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.
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
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
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
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]
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
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"
-----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
- 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.
--
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
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
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]
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/
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]
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
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. :PYou 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]
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
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 furtherWhy 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]
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.
And once you find my software useful:
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); beforesession_start()which
would
gain another 30% performanceI 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
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
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
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/
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
Sara Golemon 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/
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
-----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...)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
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