[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:94 ramiy]:
 > Yes, I know. Using those functions we can't remove all the globals, but
 we can replace the vast majority.

 My point was that in order to be able to deprecate the globals we need
 more than functions that can access them, we'd also need to add
 functions/functionality than can update them too.

 ----

 Replying to [comment:97 schlessera]:
 > However, I'd like to point out that the goal is not to improve first-
 time readability (or to even maintain it), but to improve maintainability.

 That presumes there is only one applicable goal and/or that optimizing for
 maintainability would ''not'' have a negative effect on any other goals.
 Better to verify that there are no other goals the core team thinks are of
 higher priority than assume that maintainability is the only goal worth
 optimizing for.

 Further, it would be great if you could give some specific use-case
 examples where the fact that `$wpdb` is a global variable actually caused
 real world harm vs. discussing as a theoretical concern.

 Personally, while I complete understand and agree with the theoretical
 concern when discussing an abstract use of global variables I cannot
 remember one (1) single time that I have run into a problem in my working
 professionally with WordPress when I had wish for practical reasons that
 $wpdb was not a global variable. ''(Okay, there has been one reason and
 that is for convenience of not having to first declare it `global`. But
 that's syntatical sugar, not a maintenance concern, and in our own
 libraries we have solved that with `WPLib::wpdb()`.)''

 That said, I would even argue that in WordPress core that most of the
 well-known globals are not a serious maintainability concern because they
 are in-fact well-known and there is an army of developers willing and able
 to maintain any code that contains globals.  Sure, it may ''feel'' dirty
 to work with `global` variables, but what is practical and effective does
 feel dirty. `$wpdb` fits into this category.

 If for example we deprecating `$wpdb` and doing so were to harm backward
 compatibility or even harm understandability among a significant number of
 the many people who implement WordPress sites but do not understand most
 of the syntax and semantics of classes and methods then optimizing for
 maintainability here could be more harmful than not. ''(I'm not taking a
 side on this one, I am pointing about that pursuing maintainability should
 not be viewed without question as the quest for the holy grail.)''
 ----
 OTOH, it would likely make little sense to introduce new globals as
 WordPress' code base evolves because these potential new globals are not
 yet well-known.

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