[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 ChriCo):

 Howdy.

 @jacobsantos i'm replying in a short way here:

 '''0. My "implementation'''
 Actually it was no implementation at all. I just throwed in some
 "requirements" with examples, so everyone here can follow. I think we all
 agree that we need {{{get}}}, {{{set}}}, {{{has}}} and some way to
 {{{protect}}} values from overwriting. Also some kind of "creation"
 ({{{factory}}}) of new instances should be possible. There's also a mix
 since you should be able to access the current {{{wpdb}}}-connection, but
 it should also be possible to connect to another db (create a new instance
 of this class).

 In addtion, your StorageFactory (or for Pimple its a ServiceProvider)
 could improve everything. Since we cannot use closures because of PHP 5.2,
 we have to build something arround it.

 I also had a look at your MimicCMS, but i think thats not the "right" or
 full solution/way here. Also, as i see it does not support PHP 5.2 so
 there need to be changed some internals. And thats the point: when we're
 starting to change it, i would prefer use some well known Container -
 which is already proved by many many many users (nothing against you and
 props to your work!) - as basis,

 ''Also we should keep in mind:'' We've a ton of "APIs" in WordPress and no
 ''real'' packages (e.G. a package for Query (Term, Post, ..), Customizer,
 AssetManagent (WP_Dependencies..irks) ...). So to add some
 Factories/Providers are a hugh mess currently.

 A good way would be something like:

 {{{#!php
 <?php
 .
 ├─ Query/
 |   ├─ Post.php --> WP_Query_Post
 |   ├─ Term.php --> WP_Query_Term
 |   ├─ ...
 |   ├─ composer.json --> haha..just a joke..
 |   ├─ Provider/
 |   |   ├─  Post.php --> WP_Query_Provider_Post - thats the Factory-
 implementation of your example above
 }}}

 or something similar. It's just a quick example - naming is not fixed and
 should just show how it could be implemented decoubled from WordPress with
 own UnitTests (we've no real UnitTests at all in WordPress...they are more
 like IntegrationTests..)


 '''1. To Pimple or not'''
 I just mentioned Pimple because it's easy to unterstand, well known, has a
 very short documention where you can unterstand the complete
 implementation just by reading some lines. This was just an example, so
 everyone can get a quick overview what ''could be'' implemented. I'm also
 not liking the ArrayAccess in Pimple, but thats just my personal opinion
 and that does not mean anything. I'm open to every other well known,
 tested and documented Container. And there are a lot of Containers and
 implementations out there: https://github.com/container-interop/container-
 interop#compatible-projects

 '''2. Seperate it from Core'''
 Since we're stucking with PHP 5.2, we're not able to use some existing
 implementations. This means, we have to put in a lot of effort to build an
 own implemtation of it with full test coverage.
 I totally agree in this point with you, that the ServiceContainer should
 be seperated from the Core and loaded via composer. Also it should be
 decoupled from Core to use it on its own (e.G. no usage of WordPress
 functions/classes such as {{_doing_it_wrong}} or {{WP_Error}}).

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