{"action":"created","issue":{"url":"https://api.github.com/repos/mnapoli/assembly/issues/16","repository_url":"https://api.github.com/repos/mnapoli/assembly","labels_url":"https://api.github.com/repos/mnapoli/assembly/issues/16/labels{/name}","comments_url":"https://api.github.com/repos/mnapoli/assembly/issues/16/comments","events_url":"https://api.github.com/repos/mnapoli/assembly/issues/16/events","html_url":"https://github.com/mnapoli/assembly/issues/16","id":140492057,"number":16,"title":"Need For Independent Standards Implementation","user":{"login":"XedinUnknown","id":1428973,"avatar_url":"https://avatars.githubusercontent.com/u/1428973?v=3","gravatar_id":"","url":"https://api.github.com/users/XedinUnknown","html_url":"https://github.com/XedinUnknown","followers_url":"https://api.github.com/users/XedinUnknown/followers","following_url":"https://api.github.com/users/XedinUnknown/following{/other_user}","gists_url":"https://api.github.com/users/XedinUnknown/gists{/gist_id}","starred_url":"https://api.github.com/users/XedinUnknown/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/XedinUnknown/subscriptions","organizations_url":"https://api.github.com/users/XedinUnknown/orgs","repos_url":"https://api.github.com/users/XedinUnknown/repos","events_url":"https://api.github.com/users/XedinUnknown/events{/privacy}","received_events_url":"https://api.github.com/users/XedinUnknown/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2016-03-13T14:53:07Z","updated_at":"2016-03-13T22:09:21Z","closed_at":null,"body":"Hi,\r\n\r\nCame across your repo because it is listed as standards-compliant in the docs of [`container-interop/definition-interop`](https://github.com/container-interop/definition-interop). And it's true, this is a fantastic implementation! What can I say, you have my thanks.\r\n\r\nHowever, discovered `container-interop` because I wanted to make a container implementation-agnostic library that would still use DI. As such, I want to provide default service definitions via a default provider in my lib. This is mainly for 2 reasons:\r\n\r\n1. To ease usage. The user of my library should be able to instantiate my main class, giving it the instance of the container implementation that he prefers, and start benefiting from my lib.\r\n2. Run unit tests. Can't really determine if critical services are available to my lib without defining them first.\r\n\r\nI use your lib for testing, because it's so standards-compliant, and I like it overall. And probably, the users of my lib will use it with your lib, since currently it seems to be the only standards-compliant lib. But hopefully, this will not always be the case, and I absolutely do not wish to limit them in this way.\r\n\r\nCurrently, I have 3 ways of being flexible through compliance with the `container-interop` standards:\r\n\r\n1. Create a class for each service, implementing [`DefinitionInterface`](https://github.com/container-interop/definition-interop/blob/master/src/DefinitionInterface.php). This would really bloat my lib with similar code, and will decrease its maintainability. Additionally, I would have to create a class for each [`MethodCallInterface`](https://github.com/container-interop/definition-interop/blob/master/src/ObjectInitializer/MethodCallInterface.php) whenever I need to perform additional configuration on my services, which is a lot of the times.\r\n2. Write reusable classes to streamline the process through a convenient API. But you are already doing this in your lib.\r\n3. Use your lib. This defeats the purpose of what I'm trying to achieve - independence from implementation - so I'm not even considering it.\r\n\r\nRight now, I am taking approach 2. However, this creates more opportunity for non-interoperability, which is the opposite of what this whole thing is about. Additionally, like I mentioned before, I'm copying someone else's code mostly (your code).\r\n\r\nWouldn't it be great if there was a separate, standards-compliant, container implementation-agnostic library of convenient wrappers? What I'm suggesting is the extraction of some of your classes, such as [`MethodCall`](https://github.com/mnapoli/assembly/blob/master/src/ObjectInitializer/MethodCall.php) and [`ObjectDefinition`](https://github.com/mnapoli/assembly/blob/master/src/ObjectDefinition.php), into a separate library, which `mnapoli/assembly` can then depend upon. This way, people like me can provide default service definitions with ease, while still being standards-compliant and container implementation-agnostic. On the other hand, you write that your container implementation is very simple, and anyone who isn't satisfied by it is welcome to write their own. The approach which I am proposing could give them a definition framework to build upon.\r\n\r\nWhat do you think?"},"comment":{"url":"https://api.github.com/repos/mnapoli/assembly/issues/comments/196061921","html_url":"https://github.com/mnapoli/assembly/issues/16#issuecomment-196061921","issue_url":"https://api.github.com/repos/mnapoli/assembly/issues/16","id":196061921,"user":{"login":"mnapoli","id":720328,"avatar_url":"https://avatars.githubusercontent.com/u/720328?v=3","gravatar_id":"","url":"https://api.github.com/users/mnapoli","html_url":"https://github.com/mnapoli","followers_url":"https://api.github.com/users/mnapoli/followers","following_url":"https://api.github.com/users/mnapoli/following{/other_user}","gists_url":"https://api.github.com/users/mnapoli/gists{/gist_id}","starred_url":"https://api.github.com/users/mnapoli/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mnapoli/subscriptions","organizations_url":"https://api.github.com/users/mnapoli/orgs","repos_url":"https://api.github.com/users/mnapoli/repos","events_url":"https://api.github.com/users/mnapoli/events{/privacy}","received_events_url":"https://api.github.com/users/mnapoli/received_events","type":"User","site_admin":false},"created_at":"2016-03-13T22:09:21Z","updated_at":"2016-03-13T22:09:21Z","body":"Hi @XedinUnknown, the thing is that this repository and definition-interop were part of a project that was experimental, and that has been superseded by https://github.com/container-interop/service-provider now. This new project is also experimental, it's used to try out ideas and we'll bring them back to the PHP-FIG very soon, but I don't consider it stable enough to be used anywhere."}}