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.

Reply via email to