Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only View as Markdown

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:

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

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

Derick Rethans wrote:

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.

Any reasons?

Derick

Andrey

hi,

As far as I remember we discussed that already back to the php<I don't
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

http://www.ruby-doc.org/docs/ProgrammingRuby/html/taint.htmland I like the
idea that Inspekt provides:
http://funkatron.github.com/inspekt/
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

Ferenc Kovacs wrote:

On Thu, Dec 9, 2010 at 11:14 AM, Andrey Hristov <php@hristov.com
mailto:php@hristov.com> 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

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?

You got right to the point. It's no use removing this support if the
same global state can easily be achieved in other ways, like
singletons and statics, and break thousands of applications: then you
would simply choose a different programming language.

--
Giorgio Sironi
Piccolo Principe & Web Engineer
http://giorgiosironi.blogspot.com
http://twitter.com/giorgiosironi

Adam Harvey wrote:

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.

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