[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