[wp-trac] [WordPress Trac] #37699: Death to Globals Episode #1: A Registry, A Pattern

[WordPress Trac]

#37699: Death to Globals Episode #1: A Registry, A Pattern
----------------------------+------------------
 Reporter:  wonderboymusic  |       Owner:
     Type:  enhancement     |      Status:  new
 Priority:  normal          |   Milestone:  4.7
Component:  General         |     Version:
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:
----------------------------+------------------

Comment (by MikeSchinkel):

 Replying to [comment:1 schlessera]:
 > Relying on the `WP` class name as the Service Locator is not ideal, as a
 future version of WordPress (PHP 5.3+) would most likely have `WP` as the
 root namespace. That future version would probably offer something like
 `WP\Service::get( 'wpdb' );`, so something like `WP_Service::get( 'wpdb'
 );` would be preferable. Keeping this as future-proof and flexible as
 possible should be a priority.

 As far as I know there is no conflict here.  You can have a `WP` class and
 a `WP` namespace and they won't conflict.

 >
 > '''Dependency injection'''
 >
 > So, while we cannot yet have a proper injector decide what to inject in
 what context, we can at least let the constructor take an injected
 dependency, and provide a "Poka-yoke" for as long as we are not able to do
 real injection. This would look something like this:
 >
 > {{{#!php
 > class WP_Comment_Query {
 >
 >    protected $dbh;
 >
 >    public function __construct( $query = '', $wpdb = null ) {
 >       $this->dbh = null !== $wpdb ? $wpdb : WP_service::get( 'wpdb' );
 >       // [...]
 >    }
 > }
 > }}}

 Please don't.  Let's not start adding lots of positional parameters to
 constructors so that in the future we have to  end up writing code like
 this:

 {{{#!php
 $query = new WP_Comment_Query(array(...), null, null, null, null, null,
 null, null, null, new FooBar() );
 }}}

 And please let us not preside over an explosion of classes like
 `WP_service` so that to code for WordPress requires us to remember which
 classes we need to be able to call the methods we need, even though we've
 mostly be isolated from that since day 1.

 There are better ways to handle this to create a much more usable "api",
 IMO. Everything can route through the `WP` class using helper classes
 where the methods are called using `__callStatic()`.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/37699#comment:59>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform