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

WordPress Trac noreply at wordpress.org
Wed Sep 7 15:56:54 UTC 2016


#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 jacobsantos):

 How is increased data on the debug output a valid argument?

 Moving a global to a protected attribute is a valid refactoring technique
 recommended by experts. Furthermore allows for dependency injection at a
 later date. Which is considered a good thing.

 How is it still a global? If the global changes, the internal object
 reference will not.


 Replying to [comment:83 dd32]:
 > Replying to [comment:16 wonderboymusic]:
 > > In [changeset:"38275"]:
 > > {{{
 > > #!CommitTicketReference repository="" revision="38275"
 > > Query: add a `protected` field, `$db`, (composition, as it were) to
 `WP_*_Query` classes to hold the value for the database abstraction,
 instead of importing the `global $wpdb` into every method that uses it.
 Reduces the number of global imports by 32.
 > >
 > > See #37699.
 > > }}}
 >
 > Let me start by saying that I personally want to revert this.
 >
 > This has only changed how the global is accessed, it does nothing to
 remove it. You can argue that it's reduced the number of locations that
 we'd need to alter to eventually move to a registry, but it hasn't
 actually changed the code for any better.
 > By adding a protected field to every object, when debugging and dumping
 out lots of objects, it ultimately ends up with a significant proportion
 of the debug output being references to `$wpdb`, even though that's not
 what you're actually inspecting. It gets worse when nested objects each
 have their own reference to `$wpdb` in it.
 >
 > Some people will say that dumping objects is not debugging, and one
 should use a proper IDE, to that I say yes, but sometimes that's not
 viable.
 >
 > So my comment is basically: Does using a private $db field
 '''actually''' benefit reducing globals? given the global is still there,
 and will remain there, and it's just a reference to the global anyway (So
 you might as well just call each `$this->db` reference as a global
 access).

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


More information about the wp-trac mailing list