[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:72 schlessera]:
 > Your main point is that we fail to keep WordPress development be
 accessible to "lesser-experienced" developers.
 > I wholeheartedly agree that a codebase needs to be welcoming and offer a
 learning curve that is not too steep.

 Finally. I feel prior to now that this point was falling on deaf ears.
 Thank you for recognizing the concern.

 Hopefully others can explicitly state if they agree with this or not. If
 so, then it can be used as one litmus test for a good approach.

 > However, I think that your conclusions are all backwards.

 Actually, I think you misunderstood my conclusions based on the two
 examples you contrasted.

 I mostly agreed with all you wrote in #comment:72. I agree that `WP::get(
 'whatever' )->do_something;` is better than
 `$GLOBALS['whatever']->do_something();`.  And while I disagree with your
 assertion that lesser skilled people will find is easier I think it is not
 a step too far and one that we should take if we can minimize the learning
 required to just one more bit is syntax (e.g. `::`).

  As an aside, I have recent specific experience running monthly WordPress
 coding workshops for a year. They were ostensibly supposed to be for
 professional developers but the least skilled people in our group always
 attended. I really learned a lot about what people who attend WordPress
 user groups with the intention of learning programming struggle with.

  One of key things that trigger them to assume they cannot understand
 something is '''when they see syntax they do not understand''', especially
 if they associate it with something they have already decided they can't
 understand, such as OOP.  For example this is a lot of syntax to learn for
 a non-programmer and it is intimidating to them: `WP::get( 'whatever'
 )->do_something;`

 To clarify my specific concerns:

 '''FOR THIS TICKET:'''
 1. The use of a `WP::get( 'whatever' )` seems over-architected and with no
 benefits I can perceive when we can just as easily use `WP::whatever()`.
 Especially when `whatever` is known in advance as it is with all existing
 globals. Better to create hardcoded methods that each have their own
 PHPDoc and each can trigger autocomplete in an IDE ''(without requiring
 complex machinations to get autocomplete to work.)''

 '''GENERAL ISSUES:'''
 2. For the benefit of archetypes 1 and 2 from #comment:66, let's please
 avoid adding in namespaces, interfaces and/or dependency injection that
 themers and site builders would thus need to learn and understand.

 3. And let's try to avoid namespaces and interfaces for archetypes 3-6
 whenever it could potentially result in 1 and 2 having to learn them.

 4. When using dependency injection let's (1) use the $args pattern and not
 a bunch of positional parameters, and (2) always default to the most
 common case inside the function/method that uses the dependencies.  Put a
 one-time burden on the developer of the function/method to deal with as
 much of the complexity as possible vs. forcing complexity onto tens of not
 hundreds of thousands of people who have to deal with it daily.

 > '''You can always solve a simple problem with a too complex architecture
 (and preferably wrap a simplification around it). But you will not be able
 to solve a complex problem with a too simple architecture.'''

 I strongly agree with that.

 But I also believe that we need to go the extra mile to ensure that
 complexity does not leak out and burden "lesser-experienced" developers.
 Core (and commercial plugin/theme vendors) should make ever effort to make
 it trivially easy to use WordPress and their products, respectively, even
 if it means their own code ends up being very complex.

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