{"action":"opened","issue":{"url":"https://api.github.com/repos/consolidation-org/Robo/issues/387","repository_url":"https://api.github.com/repos/consolidation-org/Robo","labels_url":"https://api.github.com/repos/consolidation-org/Robo/issues/387/labels{/name}","comments_url":"https://api.github.com/repos/consolidation-org/Robo/issues/387/comments","events_url":"https://api.github.com/repos/consolidation-org/Robo/issues/387/events","html_url":"https://github.com/consolidation-org/Robo/issues/387","id":167075187,"number":387,"title":"Clean up Robo globals","user":{"login":"greg-1-anderson","id":612191,"avatar_url":"https://avatars.githubusercontent.com/u/612191?v=3","gravatar_id":"","url":"https://api.github.com/users/greg-1-anderson","html_url":"https://github.com/greg-1-anderson","followers_url":"https://api.github.com/users/greg-1-anderson/followers","following_url":"https://api.github.com/users/greg-1-anderson/following{/other_user}","gists_url":"https://api.github.com/users/greg-1-anderson/gists{/gist_id}","starred_url":"https://api.github.com/users/greg-1-anderson/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/greg-1-anderson/subscriptions","organizations_url":"https://api.github.com/users/greg-1-anderson/orgs","repos_url":"https://api.github.com/users/greg-1-anderson/repos","events_url":"https://api.github.com/users/greg-1-anderson/events{/privacy}","received_events_url":"https://api.github.com/users/greg-1-anderson/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-07-22T15:47:44Z","updated_at":"2016-07-22T15:47:44Z","closed_at":null,"body":"Folks in #383 want more control over how Robo does output. I think there are better ways to do this than add more globals.  Before I document this, though, I'd like to do some cleanup.\r\n\r\nAs a general rule, an application's data objects should not keep references to the container -- or to other objects that keep references to the container. To keep Robo clean in this respect, I would like to split out a `Robo` class from the existing `Config` class.  The static Robo class would contain the reference to the container, and all related things, like the `input()` and `output()` methods.  `Config`, then, would keep only configuration values, not service references.  This change would affect everyone who calls `Config::getContainer()` or `Config::output()`; however, this practice is deprecated anyway, so I don't feel bad about forcing folks who do this to change to `Robo::getContainer()`.  (n.b. we can name this new static class anything.)\r\n\r\nOnce we do this, then `Config` will be free of container references. We can remove the static from ContainerBuilder, and replace it with a reference to Config via ConfigAwareInterface / Trait.\r\n\r\nAfter that, we could consider giving RoboFiles an init method, and hand them the container; then they would be able to replace ResultPrinter or the logger or whatever they want to do if they don't like the default printing options."}}
{"actor":{"display_login":"greg-1-anderson"}}