{"action":"created","issue":{"url":"https://api.github.com/repos/slimphp/Slim/issues/1358","labels_url":"https://api.github.com/repos/slimphp/Slim/issues/1358/labels{/name}","comments_url":"https://api.github.com/repos/slimphp/Slim/issues/1358/comments","events_url":"https://api.github.com/repos/slimphp/Slim/issues/1358/events","html_url":"https://github.com/slimphp/Slim/pull/1358","id":95145347,"number":1358,"title":"Questions about Container-interop integration","user":{"login":"moufmouf","id":1290952,"avatar_url":"https://avatars.githubusercontent.com/u/1290952?v=3","gravatar_id":"","url":"https://api.github.com/users/moufmouf","html_url":"https://github.com/moufmouf","followers_url":"https://api.github.com/users/moufmouf/followers","following_url":"https://api.github.com/users/moufmouf/following{/other_user}","gists_url":"https://api.github.com/users/moufmouf/gists{/gist_id}","starred_url":"https://api.github.com/users/moufmouf/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/moufmouf/subscriptions","organizations_url":"https://api.github.com/users/moufmouf/orgs","repos_url":"https://api.github.com/users/moufmouf/repos","events_url":"https://api.github.com/users/moufmouf/events{/privacy}","received_events_url":"https://api.github.com/users/moufmouf/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":8,"created_at":"2015-07-15T09:26:51Z","updated_at":"2015-07-16T19:39:15Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/slimphp/Slim/pulls/1358","html_url":"https://github.com/slimphp/Slim/pull/1358","diff_url":"https://github.com/slimphp/Slim/pull/1358.diff","patch_url":"https://github.com/slimphp/Slim/pull/1358.patch"},"body":"Hi guys,\r\n\r\nSorry to open the thread about DIC independence again, container-interop and PSR-11 editor here :)\r\n\r\nI was aware Slim was using ContainerInterop but until recently, I did not have time to get a good look at it.\r\n\r\nI'm sorry I did not step up earlier, but I have some kind of a weird feeling. I saw you have developed a `Container` class that extends Pimple and adds 9 services to it. Anyone willing to add its own container should configure it with those exact nine services.\r\n\r\nTo me, it looks like you are using containers as service locators. Let me explain:\r\n\r\n- Slim expects the services to have some name (`request`, `environment`, `router`...)\r\n- It means that rather than having the container configuring Slim, it is Slim that puts expectations on the container\r\n- It might seem strange, but having expectations on how things are named in a container is a strong assertion. For containers based\r\n  on autowiring, it is customary to name an entry in the container by the name of the class or interface it represents rather than\r\n  by an identifier.\r\n\r\nAlso, I see you have expectations about whether an entry should return always the same instance or a new instance (the 'factory' method of Pimple). For instance, the `request` entry should always be a new instance.\r\n\r\n```php\r\n/**\r\n * This service MUST return a NEW instance\r\n * of \\Psr\\Http\\Message\\ServerRequestInterface.\r\n */\r\n$this['request'] = $this->factory( //...\r\n```\r\n\r\nBe aware that container-interop states that a container **SHOULD return always the same instance**. Therefore, it is unlikely that many containers will offer the feature of creating a new instance when `get` is called. It means that you are restricting the type of containers that can be integrated into Slim.\r\n\r\nI'm starting to wonder if Slim as any need for a container. If you really want to make Slim container independent, shouldn't you rather remove all containers from Slim (and design Slim so that it can be easily configured by an external container?)\r\n\r\nLet me explain:\r\n\r\nThe App constuctor might look like this:\r\n\r\n```php\r\nclass App {\r\n\tfunction __construct(Configuration $conf) {\r\n\t\t$this->conf = $conf;\r\n\t}\r\n}\r\n```\r\n\r\nYou could have a simple `Configuration` class that is in charge of the services used by Slim.\r\n\r\n```php\r\nclass Configuration {\r\n\t// getEnvironment\r\n\t// setEnvironment\r\n\r\n\t// getRequest\r\n\t// setRequest\r\n\r\n\t// getResponse\r\n\t// setResponse\r\n\r\n\t// getRouter\r\n\t// setRouter\r\n\r\n\t//...\r\n}\r\n```\r\n\r\nOf course, if no setter is called, the getter is returning the \"default\" value for Slim.\r\n\r\nNow, from the container point-of-view, it is easy to have an \"App\" instance that binds to a \"Configuration\" instance. In this \"Configuration\",\r\nit is easy to overload any parameter used by Slim.\r\n\r\nThis way, Slim is both container independent AND container friendly. No need for container-interop, nor PSR-11, nor Pimple!\r\n\r\nI'm by no means a Slim expert, so I'm probably overlooking several problems, but I'd be curious to know what you think about it.\r\n\r\n\r\n**Important**: I'm not saying that Slim should not rely on container-interop or PSR-11. There are plenty of very good use cases for using\r\ncontainer-interop, but I'm not sure the usage I see today in the code is the best one. Have a look at mnapoli's [Invoker](https://github.com/PHP-DI/Invoker) project. It makes use \r\nof container-interop in a special way (resolving function parameters based on type-hint or parameter name, just like in AngularJS).\r\nActually, the more I think about it, the more I'd like to see such a feature in Slim :) But that's a completely different issue.\r\n\r\n@mnapoli, I'd be curious to know what you think about my proposal here. Do you think using Container-interop the way it is used today makes sense?\r\n"},"comment":{"url":"https://api.github.com/repos/slimphp/Slim/issues/comments/122064620","html_url":"https://github.com/slimphp/Slim/pull/1358#issuecomment-122064620","issue_url":"https://api.github.com/repos/slimphp/Slim/issues/1358","id":122064620,"user":{"login":"akrabat","id":33135,"avatar_url":"https://avatars.githubusercontent.com/u/33135?v=3","gravatar_id":"","url":"https://api.github.com/users/akrabat","html_url":"https://github.com/akrabat","followers_url":"https://api.github.com/users/akrabat/followers","following_url":"https://api.github.com/users/akrabat/following{/other_user}","gists_url":"https://api.github.com/users/akrabat/gists{/gist_id}","starred_url":"https://api.github.com/users/akrabat/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/akrabat/subscriptions","organizations_url":"https://api.github.com/users/akrabat/orgs","repos_url":"https://api.github.com/users/akrabat/repos","events_url":"https://api.github.com/users/akrabat/events{/privacy}","received_events_url":"https://api.github.com/users/akrabat/received_events","type":"User","site_admin":false},"created_at":"2015-07-16T19:39:14Z","updated_at":"2015-07-16T19:39:14Z","body":"I understand better now.\r\n\r\nHow would a use configure their own notFoundHandler so that it was lazy loaded as most requests wouldn't need it to be instantiated?"}}