Hi Matthew, Thanks for the info. I had took some time to read the docs and I hope you don't take this the wrong way, but it seems to me you guys are over thinking the problem. I think PSR-11 ended up working out great for this. To build a cross framework service is now very easy, and asking a developer to register your libraries factory with what ever framework or container they are using doesn't seem like a big deal. The only issue left to really achieve what you guys attempting is simply getting at the applications configuration. It's the frameworks/containers config that's a bit tricky to get to.
Alias's, Invokables, delegators/decorators, abstract factories really seem like implementation details to me. These are huge selling features of Zend Service Manager and why one might choose to use it. On the flip side, not having these features and the extra code that go with it, are huge selling points of Pimple and Slim. So far knowing that I don't have these features everywhere has not hindered me from building modules that span across frameworks. If you ask me, the problems you're trying to solve here were best addressed by the container-interops "container within a container" as it left implementations alone and gave the users a middle layer they could keep long enough to migrate away from a particular container. I thought this was a great idea. Unfortunately that was dropped in psr-11. Going back to Woody and Alessandro comments, it seems to me a simple interface like say, ConfigProviderInterface with a simple method of getConfig() and one interface for the config like ConfigInterface with methods like has($key) and get($key) would solve the issue of having services that you can use across all the compliant frameworks and containers. I don't think registering a factory and adding a little config with your container of choice is too much to ask a developer to do, it's just hard to get at the config as a generic service. Westin Shafer On Tuesday, February 13, 2018 at 7:25:41 AM UTC-7, Matthew Weier O'Phinney wrote: > > On Mon, Feb 12, 2018 at 7:07 PM, Westin Shafer <wsh...@gmail.com > <javascript:>> wrote: > > That said, there is still one issue that has hit me on each of > > these libraries getting configuration out of the different containers. > As > > each framework stores configuration in a different way there seems to be > no > > uniform way to retrieve it. This leads to unnecessary implementation > > specific code. > <snip> > > As you can see, this is one area where PSR-11 could use some > improvement. > > I did see a thread dated few years ago where someone had started a > > conversation to address this. Has there been any movement or other > > conversations about this? If not, is there anything I can do to help > move > > this conversation forward? > > There has been some work on it in the container-interop group; the > project is called "service providers": > > - https://github.com/container-interop/service-provider > > There's not been a ton of movement on it, but the idea is pretty solid. > > In parallel, the ZF community has been working on a number of > "zend-{container type}-config" projects that are attempting to > identify common configuration features of many containers, and provide > a translation layer around them. So far, we've identified: > > - aliases (though these could likely be addressed by a specialized factory > type) > - invokables (constructor-less classes; could also be addressed by a > specialized factory type) > - factories > - delegators/decorators (these are similar to the "extensions" > functionality of the service-provider project) > - fallbacks/abstract factories (these produce an instance for any > given service name) > > I'm involved with the container-interop team, but haven't had time to > drive any discussions recently. I'm sure I speak for the others when I > say your feedback and input would be welcome! > > -- > Matthew Weier O'Phinney > mweiero...@gmail.com <javascript:> > https://mwop.net/ > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/ea877952-a54a-4702-91c2-3d5f52d48025%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.