Phase out the use of the global keyword

[prettyboymp]

I'd like to request phasing out the use of the global keyword in exchange for get current instance methods. There are a couple reasons for this:

1. Help reduce development errors by reducing the risk of variable name conflicts. I've often run into issues where I will name a local variable something before calling a core function that uses a global variable named the same thing.
   

2. Clean up duplicate code. Lines like the below would only need to exist in the get method.

   global $wp_styles;
   if ( !is_a($wp_styles, 'WP_Styles') ) $wp_styles = new WP_Styles();
   

When doing this, the super globals would still need to be available for backwards compatibility.

[dd32]

I dont think this'll be done anytime soon honestly.

You are right about variable conflicts, and its annoying as hell sometimes, but many themes and plugins also rely upon the global vars being available at this stage, many of the API functions/filters do not pass enough information right now for it to be avoided.

In order to this, its going to require a lot of back-compat breaking and a lot of filter/action re-working (mainly adding args). This can basically be thrown on the pile of items which would be great in core, we just need a release where we can break a lot of back-compat with.

IMO some vars should stay, $post and the like for example, but as many vars which are unexpected should go, along with vars which are actually objects (rewrite, query, etc)

[prettyboymp]

I don't know that even $post should still be accessed as a global variable. Since it is just pointing to the current post within the $wp_query posts array. Shouldn't it be like:

$wp_query &= WP_Query::get_instance(); or &= wp_get_wp_query_instance();
$post = $wp_query->get_the_query();

//and if php4 is finally dropped
$post = WP_Query::get_instance()->get_the_query();

[ryan]

We've been massaging things in this direction. Eventually we'll get there. Let's take it case by case.