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

WordPress Trac noreply at wordpress.org
Fri Sep 2 10:24:02 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 schlessera):

 Replying to [comment:66 MikeSchinkel]:

 You split your argument across two different tickets, so it is difficult
 to respond. I'll just generally address the issue you're raising here,
 knowing that this also applies to some of your arguments commented on
 ticket #36335 .

 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. However, I think that your
 conclusions are all backwards.

 First of all, an example:

 {{{#!php
 <?php
 global $whatever;
 $whatever->do_something();
 }}}

 I posit that this is more difficult to comprehend and creates more issues,
 than something like this:

 {{{#!php
 <?php
 WP::get( 'whatever' )->do_something;
 }}}

 The first example creates two separate issues:
 1. You need to explicitly tell the code that you're referencing a global.
 Apart from immediately showing developers a way of how _not_ to do it, you
 also assume that they have a basic knowledge of local/global namespace
 differences.
 2. If the developer uses this in the wrong context (when the global was
 not initialized yet), it will create very confusing issues/errors that are
 hard to debug.

 The second example improves upon this in the following way:
 1. There's no "pre-qualifying" something before using it. You tell WP what
 you need, and it will be ready.
 2. If you use this in the wrong context, the `WP` class can immediately
 show a clear error explaining why the developer is using this the wrong
 way. So, the `WP` class identifies errors during development time, instead
 of deferring this to the plugin review team.

 More generally:

 When trying to have a complex system be more approachable for laymen, you
 build a complex, flexible system first that allows for all advanced
 usages, and then provide convenience functions/wrappers/facades for the
 common use cases.

 The other way around just doesn't work. You cannot create a more simple
 system, and the provide more advanced wrappers for advanced use cases.
 This will result in what we have now with WordPress: you have a more
 simple system that covers the common use cases, and all the more advanced
 developers need to use hack and workarounds to solve their problems.

 Why do you think that wordpress.com does not use the .org Core? It is
 simply not usable as is for more complex scenarios...

 Your fear probably comes from frameworks like Symfony or Zend. They can
 account for the most complex sites/apps, but if you want to build a simple
 blog, you'll need to deal with hugely complex abstractions before getting
 anything done.

 However, I think WordPress should go a similar route like the (opinionated
 and controversial) Laravel. Laravel has pretty much the exact same
 abstractions and architectures behind the scenes than Symfony (and even
 uses most of Symfony Core as is). But it provides its clever Facades for
 people that don't care about any of this and just want to solve their
 problem in a few lines of code. More advanced developers, however, can
 still get direct access to the dependency injection container or create
 completely custom handlers.

 '''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.'''

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


More information about the wp-trac mailing list