{"action":"opened","issue":{"url":"https://api.github.com/repos/sparkphp/spark/issues/39","labels_url":"https://api.github.com/repos/sparkphp/spark/issues/39/labels{/name}","comments_url":"https://api.github.com/repos/sparkphp/spark/issues/39/comments","events_url":"https://api.github.com/repos/sparkphp/spark/issues/39/events","html_url":"https://github.com/sparkphp/spark/issues/39","id":112874335,"number":39,"title":"Support container interoperation?","user":{"login":"elazar","id":15487,"avatar_url":"https://avatars.githubusercontent.com/u/15487?v=3","gravatar_id":"","url":"https://api.github.com/users/elazar","html_url":"https://github.com/elazar","followers_url":"https://api.github.com/users/elazar/followers","following_url":"https://api.github.com/users/elazar/following{/other_user}","gists_url":"https://api.github.com/users/elazar/gists{/gist_id}","starred_url":"https://api.github.com/users/elazar/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/elazar/subscriptions","organizations_url":"https://api.github.com/users/elazar/orgs","repos_url":"https://api.github.com/users/elazar/repos","events_url":"https://api.github.com/users/elazar/events{/privacy}","received_events_url":"https://api.github.com/users/elazar/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2015-10-22T19:32:29Z","updated_at":"2015-10-22T19:32:29Z","closed_at":null,"body":"See related discussion on rdlowrey/auryn#77, in particular this quote by @shadowhand:\r\n\r\n> I think there is potentially a tiny bit of convenience in having a common interface that allows people to replace the injector that is used by a framework, _even though the framework does not **need** to depend on a specific injector_, because pushing all injector configuration onto the user is not convenient for anyone.\r\n\r\nI agree with this. Even if FIG never reaches a resolution on the container versus service locator argument, I still think there's potential value in supporting [container inoperation](https://github.com/container-interop/container-interop/blob/master/docs/ContainerInterface.md). More specifically, it would allow Spark users the choice of which container they use, even if we as Spark developers tend to choose Auryn in particular.\r\n\r\nSee also my argument for Auryn interoperation support and how an implementation could work in rdlowrey/auryn#127. The only thing I'm unsure of is specific implementation details for `ContainerInterface->has()`, which is open for discussion.\r\n\r\nThoughts?"}}