# Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only - Thread: https://externals.io/message/50921 - Original archive: https://news-web.php.net/php.internals/50921 - Started by Andrey Hristov on 2010-12-09T10:14:22+00:00 - Messages: 50 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/50921.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #50921 — Andrey Hristov — 2010-12-09T10:14:22+00:00 URL: https://externals.io/message/50921#50921 Hi guys, the topic says most of it. What do you think about deprecating the global keyword and $GLOBALS with it? Together with this making $_REQUEST, $_GET and $_POST read-only as they should be used only to read-only anyway. The reason for global + GLOBALS is that these are abused and which leads to spaghetti programs, when used by unexperienced users. Also they have impact on side effects from functions that don't only rely their parameters. Best, Andrey --- ## #50922 — Reindl Harald — 2010-12-09T10:19:51+00:00 URL: https://externals.io/message/50921#50922 · In reply to: #50921 Please do not global + GLOBALS can be used in so many ways and you would break 200.000 LOC only here which is running with reporting `E_STRICT` in a production environment The same for making $_GET/$_POST/$_REQUEST readonly I know that it is not best practice, but sometimes it makes life easier to fetch $_POST in a method which overwrites a parent method and add a single item before the parent is processing $_POST Yes, there are many other ways to do the same but BC-breaking trigger a lot of work and testing Am 09.12.2010 11:14, schrieb Andrey Hristov: > Hi guys, > the topic says most of it. What do you think about deprecating the global keyword and $GLOBALS with it? Together > with this making $_REQUEST, $_GET and $_POST read-only as they should be used only to read-only anyway. > > The reason for global + GLOBALS is that these are abused and which leads to spaghetti programs, when used by > unexperienced users. Also they have impact on side effects from functions that don't only rely their parameters. > > Best, > Andrey -- Mit besten Grüßen, Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / software-development / cms-solutions p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 icq: 154546673, http://www.thelounge.net/ --- ## #50923 — james.butler@edigitalresearch.com — 2010-12-09T10:22:22+00:00 URL: https://externals.io/message/50921#50923 · In reply to: #50921 +1 million because GLOBAL scope is horrid (generally) and is thoroughly abused -1 million because it will be the most horrific BC break since time began and I imagine it will break so much code that is currently in the wild... In short I like it but I'm not sure how it would ever get implemented without breaking stuff... (this is where the clever core developers can propose some easy method I can't think of right now) -----Original Message----- From: Andrey Hristov [mailto:php@hristov.com] Sent: 09 December 2010 10:14 To: PHP Internals List Subject: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only Hi guys, the topic says most of it. What do you think about deprecating the global keyword and $GLOBALS with it? Together with this making $_REQUEST, $_GET and $_POST read-only as they should be used only to read-only anyway. The reason for global + GLOBALS is that these are abused and which leads to spaghetti programs, when used by unexperienced users. Also they have impact on side effects from functions that don't only rely their parameters. Best, Andrey --- ## #50924 — Andrey Hristov — 2010-12-09T10:23:20+00:00 URL: https://externals.io/message/50921#50924 · In reply to: #50922 Reindl Harald wrote: > Please do not > > global + GLOBALS can be used in so many ways and you would break > 200.000 LOC only here which is running with reporting `E_STRICT` > in a production environment what happened after register_globals was introduced and registering of globals was switched off? > The same for making $_GET/$_POST/$_REQUEST readonly > I know that it is not best practice, but sometimes > it makes life easier to fetch $_POST in a method > which overwrites a parent method and add a single > item before the parent is processing $_POST It's bad practice. > Yes, there are many other ways to do the same but > BC-breaking trigger a lot of work and testing > > Am 09.12.2010 11:14, schrieb Andrey Hristov: > > […] > > Best, Andrey --- ## #50925 — Andrey Hristov — 2010-12-09T10:26:25+00:00 URL: https://externals.io/message/50921#50925 · In reply to: #50923 James Butler wrote: > +1 million because GLOBAL scope is horrid (generally) and is thoroughly abused > -1 million because it will be the most horrific BC break since time began and I imagine it will break so much code that is currently in the wild... how hard it will be to grep for "global" and $GLOBALS? > In short I like it but I'm not sure how it would ever get implemented without breaking stuff... (this is where the clever core developers can propose some easy method I can't think of right now) INI variable, like register_globals > > -----Original Message----- > From: Andrey Hristov [mailto:php@hristov.com] > Sent: 09 December 2010 10:14 > To: PHP Internals List > Subject: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only > > Hi guys, > the topic says most of it. What do you think about deprecating the > global keyword and $GLOBALS with it? Together with this making > $_REQUEST, $_GET and $_POST read-only as they should be used only to > read-only anyway. > > The reason for global + GLOBALS is that these are abused and which leads > to spaghetti programs, when used by unexperienced users. Also they have > impact on side effects from functions that don't only rely their parameters. > > Best, > Andrey > Best, Andrey --- ## #50930 — Eloy Bote Falcon — 2010-12-09T10:46:12+00:00 URL: https://externals.io/message/50921#50930 · In reply to: #50924 2010/12/9 Andrey Hristov > Reindl Harald wrote: > > > […] > > what happened after register_globals was introduced and registering of > globals was switched off? > > > The same for making $_GET/$_POST/$_REQUEST readonly > > […] > > It's bad practice. > > > Yes, there are many other ways to do the same but > > […] > Best, > Andrey > > -- > > > > Is copying the POST variables into another variables best practice (like a manual register_globals)? In the global scope of the application I think it's cleaner to work with $_POST to overwrite the values than copying the items into variables. Inside a function/method, I agree that it's best practice to pass $_POST as a parameter and then overwrite the values as you need. Regards, Eloy Bote Falcon. --- ## #50932 — Andrey Hristov — 2010-12-09T10:53:08+00:00 URL: https://externals.io/message/50921#50932 · In reply to: #50930 Eloy Bote Falcon wrote: > 2010/12/9 Andrey Hristov > > > […] > > > Is copying the POST variables into another variables best practice (like a > manual register_globals)? In the global scope of the application I think > it's cleaner to work with $_POST to overwrite the values than copying the > items into variables. Inside a function/method, I agree that it's best > practice to pass $_POST as a parameter and then overwrite the values as you > need. $_POST is POST, incoming variables, everything else is a hack. If you expect that the variable might change then copy it, at least someone this will signal that the value might have been changed somewhere. > > Regards, > > Eloy Bote Falcon. > Best, Andrey --- ## #50933 — Derick Rethans — 2010-12-09T10:53:18+00:00 URL: https://externals.io/message/50921#50933 · In reply to: #50921 > the topic says most of it. What do you think about deprecating the global > keyword and $GLOBALS with it? Together with this making $_REQUEST, $_GET and > $_POST read-only as they should be used only to read-only anyway. No thanks. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #50934 — Andrey Hristov — 2010-12-09T10:59:06+00:00 URL: https://externals.io/message/50921#50934 · In reply to: #50933 Derick Rethans wrote: > > > > […] > > No thanks. Any reasons? > Derick > Andrey --- ## #50935 — Alain Williams — 2010-12-09T11:03:38+00:00 URL: https://externals.io/message/50921#50935 · In reply to: #50932 > > […] > > $_POST is POST, incoming variables, everything else is a hack. If you > expect that the variable might change then copy it, at least someone > this will signal that the value might have been changed somewhere. What is the real difference between operating on $_POST directly and some other copy of it ? Not everyone writes huge, complicated scripts written by many different people. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include > > > […] > > What is the real difference between operating on $_POST directly > and some other copy of it ? Not everyone writes huge, complicated scripts > written by many different people. > conceptual. If it is a copy it means something was changed, right? Andrey --- ## #50937 — Pierre Joye — 2010-12-09T11:15:20+00:00 URL: https://externals.io/message/50921#50937 · In reply to: #50921 hi, As far as I remember we discussed that already back to the php discussions. It was not accepted because of the little gains in regard to the major BC breaks. However I would prefer, as far as it is technically possible, deprecate their usage (notices/warnings) and promote filter usage instead. The filter API can also be improved to match what we can find in other platform (perl's cgi module for example is quite good) and make the input data processing even more user-friendly. Cheers, >  Hi guys, > the topic says most of it. What do you think about deprecating the global > keyword and $GLOBALS with it? Together with this making $_REQUEST, $_GET and > $_POST read-only as they should be used only to read-only anyway. > > The reason for global + GLOBALS is that these are abused and which leads to > spaghetti programs, when used by unexperienced users. Also they have impact > on side effects from functions that don't only rely their parameters. > > Best, > Andrey > > -- > > > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #50938 — Ferenc Kovacs — 2010-12-09T11:21:11+00:00 URL: https://externals.io/message/50921#50938 · In reply to: #50921 > Hi guys, > the topic says most of it. What do you think about deprecating the global > keyword and $GLOBALS with it? Together with this making $_REQUEST, $_GET and > $_POST read-only as they should be used only to read-only anyway. > > The reason for global + GLOBALS is that these are abused and which leads to > spaghetti programs, when used by unexperienced users. Also they have impact > on side effects from functions that don't only rely their parameters. > > Best, > Andrey > > Please next time write an rfc before starting a thread like this. I'm pretty much against the idea. That would be the most dramatic change in the language in the history of php. The register_globals is/was a much bigger problem/bad practice and it take 10 years to remove it(we are almost there...). And to fix the applications, one would either completely restructure all of the functions/methods to pass all of the required data from the global scope, or they would do the easy way: export all of the global variables into a singleton registry. From a Framework point of view, they should save all of the (super)global variables from the global scope, because the frameworks doesn't use/run code in the global scope except the bootstrap, so they couldn't access that either, but they won't know what the developer who uses the framework want's to access from the global scope. And what about global constants? They are also screwing up the Dependency Injection, and the static functions/properties, and the singletons also. Should we ban those? Tyrael --- ## #50939 — Ferenc Kovacs — 2010-12-09T11:34:29+00:00 URL: https://externals.io/message/50921#50939 · In reply to: #50937 > hi, > > As far as I remember we discussed that already back to the php mention it> discussions. It was not accepted because of the little > gains in regard to the major BC breaks. > > However I would prefer, as far as it is technically possible, > deprecate their usage (notices/warnings) and promote filter usage > instead. The filter API can also be improved to match what we can find > in other platform (perl's cgi module for example is quite good) and > make the input data processing even more user-friendly. > > Cheers, > > yeah, to throw in something: I like the Safe levels and the tainted support in ruby: http://www.ruby-doc.org/docs/ProgrammingRuby/html/taint.html and I like the idea that Inspekt provides: http://funkatron.github.com/inspekt/ "Inspekt acts as a firewall API between user input and the rest of the application. It takes PHP superglobal arrays, encapsulates their data in an "cage" object, and destroys the original superglobal. Data can then be retrieved from the input data object using a variety of accessor methods that apply filtering, or the data can be checked against validation methods. Raw data can only be accessed via a 'getRaw()' method, forcing the developer to show clear intent." I like the explicitness of the filtering, but I think that we should allow the developers to decide whether to use it or not. Tyrael --- ## #50940 — Rasmus Lerdorf — 2010-12-09T12:04:26+00:00 URL: https://externals.io/message/50921#50940 · In reply to: #50939 > > > > […] > yeah, to throw in something: > I like the Safe levels and the tainted support in ruby: > http://www.ruby-doc.org/docs/ProgrammingRuby/html/taint.html > > and I like the > idea that Inspekt provides: > http://funkatron.github.com/inspekt/ > > "Inspekt acts as a firewall API between user input and the rest of the > application. It takes PHP superglobal arrays, encapsulates their data in an > "cage" object, and destroys the original superglobal. Data can then be > retrieved from the input data object using a variety of accessor methods > that apply filtering, or the data can be checked against validation methods. > Raw data can only be accessed via a 'getRaw()' method, forcing the developer > to show clear intent." > > I like the explicitness of the filtering, but I think that we should allow > the developers to decide whether to use it or not. You just described exactly how the filter extension works when you enable a default filter. -Rasmus --- ## #50941 — Andrey Hristov — 2010-12-09T12:15:41+00:00 URL: https://externals.io/message/50921#50941 · In reply to: #50938 Ferenc Kovacs wrote: > > > On Thu, Dec 9, 2010 at 11:14 AM, Andrey Hristov > wrote: > > Â Hi guys, > the topic says most of it. What do you think about deprecating the > global keyword and $GLOBALS with it? Together with this making > $_REQUEST, $_GET and $_POST read-only as they should be used only to > read-only anyway. > > The reason for global + GLOBALS is that these are abused and which > leads to spaghetti programs, when used by unexperienced users. Also > they have impact on side effects from functions that don't only rely > their parameters. > > Best, > Andrey > > > Please next time write an rfc before starting a thread like this. a RFC can crystalize from this thread. > I'm pretty much against the idea. > That would be the most dramatic change in the language in the history of > php. pretty dramatic change was the change to the object model between 4 and 5. Dropping the usage of references, dropping of exchange of $this. And also register_globals. register_globals was harder to fix, because you can't just grep and find what variables you need from the URLs. Situation is different with $GLOBALS and "global", as a single grep can show you whether an application needs change or not. > The register_globals is/was a much bigger problem/bad practice and it > take 10 years to remove it(we are almost there...). > And to fix the applications, one would either completely restructure all > of the functions/methods to pass all of the required data from the > global scope, or they would do the easy way: export all of the global > variables into a singleton registry. I am not against global variables, I'm against usage of $GLOBALS and "global". > From a Framework point of view, they should save all of the > (super)global variables from the global scope, because the frameworks > doesn't use/run code in the global scope except the bootstrap, so they > couldn't access that either, but they won't know what the developer who > uses the framework want's to access from the global scope. > And what about global constants? They are also screwing up the > Dependency Injection, and the static functions/properties, and the > Â singletons also. Â Should we ban those? no, you got me wrong. I will repeat - global variables won't cease to exist, but $GLOBALS and "global" as means to access them should be removed. If a function needs data it should get it passed to it. > Tyrael Andrey --- ## #50942 — Ilia Alshanetsky — 2010-12-09T12:23:39+00:00 URL: https://externals.io/message/50921#50942 · In reply to: #50921 >  Hi guys, > the topic says most of it. What do you think about deprecating the global > keyword and $GLOBALS with it? Together with this making $_REQUEST, $_GET and > $_POST read-only as they should be used only to read-only anyway. I do not believe that making these read-only is going to yield any performance benefits and the chances of this breaking many scripts is quite large. -1 Ilia --- ## #50943 — james.butler@edigitalresearch.com — 2010-12-09T12:27:19+00:00 URL: https://externals.io/message/50921#50943 · In reply to: #50921 -----Original Message----- From: Ilia Alshanetsky [mailto:ilia@prohost.org] >  Hi guys, > the topic says most of it. What do you think about deprecating the global > keyword and $GLOBALS with it? Together with this making $_REQUEST, $_GET and > $_POST read-only as they should be used only to read-only anyway. I do not believe that making these read-only is going to yield any performance benefits and the chances of this breaking many scripts is quite large. -1 Ilia ------- One other potential negative... By making them read only, are you removing the ability to scrub/delete them? Surely this is bad point? J --- ## #50944 — Alain Williams — 2010-12-09T12:27:47+00:00 URL: https://externals.io/message/50921#50944 · In reply to: #50941 > no, you got me wrong. I will repeat - global variables won't cease to > exist, but $GLOBALS and "global" as means to access them should be > removed. If a function needs data it should get it passed to it. By & large yes, but in small/medium scripts it can be really useful to have things like a globally scoped $dbh - so it doesn't clutter up function calls. Yes: if the script grows to the point where it needs more than one database handle then the script will need to be refactored, but for huge numbers of scripts that will never be the case. If you ban global variables people will just bung the values into $_SESSION to get the same effect -- that would be even worse! -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include the topic says most of it. What do you think about deprecating the global > keyword and $GLOBALS with it? Together with this making $_REQUEST, $_GET and > $_POST read-only as they should be used only to read-only anyway. -1 here. No question that if you were developing a new language with similar design goals to PHP (but learning from the missteps), you'd probably make the superglobal analogues read only and skip the idea of $GLOBALS altogether, but there's just too much code out there that relies on these "features" working. Adam --- ## #50946 — Andrey Hristov — 2010-12-09T12:46:14+00:00 URL: https://externals.io/message/50921#50946 · In reply to: #50945 Adam Harvey wrote: > > > […] > > -1 here. No question that if you were developing a new language with > similar design goals to PHP (but learning from the missteps), you'd > probably make the superglobal analogues read only and skip the idea of > $GLOBALS altogether, but there's just too much code out there that > relies on these "features" working. There were many apps which relied on register_globals but register_globals was introduced. There were many apps which relied on references in PHP4, but the object model changed in 5, references too. There are apps which rely on magic_quotes, but magic quotes are deprecated. When some feature is changed or deprecated there will always be applications that need to change. > Adam > Andrey --- ## #50947 — Rasmus Lerdorf — 2010-12-09T12:56:15+00:00 URL: https://externals.io/message/50921#50947 · In reply to: #50946 > There were many apps which relied on register_globals but > register_globals was introduced. > There were many apps which relied on references in PHP4, but the object > model changed in 5, references too. > There are apps which rely on magic_quotes, but magic quotes are deprecated. > When some feature is changed or deprecated there will always be > applications that need to change. Andrey, you have posted 9 messages on this in the past 3 hours. We have heard you. You don't need to keep saying the same thing over and over. And for the record, I strongly disagree with changing this. -Rasmus --- ## #50950 — Lester Caine — 2010-12-09T14:57:11+00:00 URL: https://externals.io/message/50921#50950 · In reply to: #50947 Rasmus Lerdorf wrote: > Andrey, you have posted 9 messages on this in the past 3 hours. We have > heard you. You don't need to keep saying the same thing over and over. > > And for the record, I strongly disagree with changing this. As someone who always seems to be doing things the wrong way, simply processing the $_REQUEST, killing anything that I don't like and adding the missing elements is how my whole codebase works. Duplicating it does not make sense when there are some complex elements in the posted form! -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #50951 — keisial@gmail.com — 2010-12-09T16:12:13+00:00 URL: https://externals.io/message/50921#50951 · In reply to: #50941 Andrey Hristov wrote: > I am not against global variables, I'm against usage of $GLOBALS and > "global". So how do you support global variables by banning the two ways they can be accessed? -1 > > […] > > no, you got me wrong. I will repeat - global variables won't cease to > exist, but $GLOBALS and "global" as means to access them should be > removed. If a function needs data it should get it passed to it. That's like trying to forbid TSRMLS_FETCH() in php source saying "just use TSRMLS_DC instead". Sure it is a nice goal but a) That's not always feasible [without rewriting an insane amount of code] b) It's not a restriction that should be imposed by the language. --- ## #50952 — Reindl Harald — 2010-12-09T16:15:15+00:00 URL: https://externals.io/message/50921#50952 · In reply to: #50946 Am 09.12.2010 13:46, schrieb Andrey Hristov: > There were many apps which relied on register_globals but register_globals was introduced. > There were many apps which relied on references in PHP4, but the object model changed in 5, references too. > There are apps which rely on magic_quotes, but magic quotes are deprecated. > When some feature is changed or deprecated there will always be applications that need to change. that is not a valid reason for bc-breaking if you do not want $GLOBALS in your functions do not use them but do not force bc-breaks which are hurting others without any sense --- Next page: https://externals.io/message/50921.md?page=2