Eloy Bote Falcon wrote:
2010/12/9 Andrey Hristov <p...@hristov.com>

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

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




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

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

Reply via email to