[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