[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:  Awaiting Review
Component:  General         |     Version:
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:
----------------------------+------------------------------

Comment (by jdgrimes):

 No reason not to make a long ticket longer, right? So at the risk of
 sounding preachy (not intended that way, really just thinking out loud
 here):

 I think that a big reason why the core team has difficulty handling
 tickets like this is that they are too abstract. Most of us, as
 developers, live in the abstract. Many of WordPress's core committers do a
 great job at something that many of us sometimes fail at, and that is,
 living in the real world. To do this, the core team thinks like a user.
 The users always have problems that they need to solve. WordPress's job is
 to help them solve those problems.

 Now, before you start thinking that that leaves developers out in the
 cold, remember that to a large degree, WordPress tries to grey the line
 between the user and the developer. We all understand that this has to be
 done with care, and that it can have bad side-effects at times. Set that
 aside for a moment. Because what it really means is that "art" developers
 like some of us are "users" every bit as much as newbie coders and folks
 who are too afraid to even copy and paste code. The problem is that the
 other two groups approach problems differently than we do. They don't have
 the answers or the solutions. They have the problems. We are the other way
 around. We have all of the answers (or sometimes think we do ;-), but we
 can get so immersed into the abstract world of ideal solutions that we
 forget to do something really simple: have a problem to solve in the first
 place.

 This ticket's OP says that a lot of things are bad. While everybody here,
 including every last member of the core team, probably agrees on that, it
 is still subjective and ultimately irrelevant to them (the core team).
 Because it is irrelevant to the user.

 Now, we all know that in one way or another, it really ''isn't''
 irrelevant to the user. But why? ''What is the problem?'' Why is a
 solution needed? How is the end-user (including the full spectrum of
 developers), benefited?

 The only mention of anything like that in the OP is:

 > Training people to assume that globals will always be set to the value
 they expect is ... bad.

 Ah, now we have a problem: new developers see us using globals, and that
 encourages them to use them, too. And we all know that this is a problem
 because globals can very unexpectedly not have the value that you expect
 them to have when you least expect it. But people won't know that, because
 if it ever happened to most of the WordPress globals things would break so
 bad that we'd notice it right way.

 So we could re-word this problem this way: we are encouraging people to
 write more fragile code, without them even realizing it.

 Now that we have a problem, we have a concrete starting point from which
 to begin diving into our abstract world of solutions. And we can always
 come back and know for sure whether a proposed "solution" really is one,
 because we can check whether it solves the problem. (Test-driven
 development!) The person who comes along and commits that solution will
 also now know that they are actually accomplishing something, not just
 churning code "because developers", and exactly why it needs to be done,
 and that we've thought about how it relates to end-users' (including us!)
 real-world problems.

 Keeping this problem in mind means that the solution isn't necessarily as
 simple as just removing globals. The goal is to set (and probably provide)
 a pattern that developers ''should'' be following instead of using
 globals. This means that we need to keep in mind not just reducing
 fragility, but also making something that developers will actually
 understand enough to use. Otherwise, they may just revert to something
 easier, like... I know! Globals FTW!

 It also indicates that we may want to actually provide an API that plugin
 developers can use for their own would-be-globals, not just produce a
 pattern and then expect them to follow it. Because globals aren't just a
 pattern, they are a really, really easy to use feature. There is no
 special implementation in your plugin's code to handle them, no custom
 classes, functions, etc. You just have the `global` keyword, and you're
 all set. So again, in order to actually solve this problem it is better if
 we provide something as simple as possible.

 So now we can look at some concrete constraints to consider as we move
 forward. And I realize that there are many other constraints, both
 concrete and abstract, that we could come up with. There are possibly
 other "problems" that relate to globals that need to be solved. So let's
 identify 'em and solve 'em. For us! For all the devs!! ''For the users!!
 ''FOR THE WORLD!!! [insert hysterical yell here]

 ----

 '''TL;DR:''' As developers we sometimes jump to solutions too quick,
 before actually coming up with a clear problem that we are solving so that
 we (and the core committers) will know when we've found a solution and not
 just a rabbit trail.

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