Also available to help out. Maybe, an update from the last time I posted could be useful. The implementation I had written for the purposes of demonstrating my take on lookup delegation is now dhii/di <https://github.com/Dhii/di>. It achieves that by every child container being able to reference its parent, and the top-most container obtained this way is always passed to the service factories. That container then delegates lookup to its child containers. This package is right now being used for 2 major WordPress plugin projects. I approached it in the way Rasmus describes, i.e. I "fake" a top-most WordPress container in the plugin, and attach another composite container to it, and then a container per plugin/addon of the same "family". Of course I use the service provider pattern everywhere, but for one of the projects I use a convention, whereby every "module" can contain a `services.php` file. This file MUST return either an instance of `ServiceProviderInterface`, or an array of service factories, which internally gets wrapped in a generic immutable service provider. All these providers are then given to the container responsible for the plugin. What I mean to say here is that there's no need for the approaches to be mutually exclusive. I think they are both beneficial, and in my projects they co-exist.
On Tuesday, March 28, 2017 at 12:01:48 PM UTC+2, David Négrier wrote: > > Hey list! > > > PSR-11 has been accepted so we have standardized how to fetch entries from > containers. > > The next logical step is to find a common way to put things into a > container. More generally, the goal we are seeking is to make it possible > for a package author to provide/modify entries in any container (rather > than having to write a module/bundle for each framework as it's the case > today as I described in this talk: > https://thecodingmachine.github.io/forumphp2016talk/index_en.html#60). > > > Let's be clear that the goal is NOT to define a single way of configuring > a container. Each container has its own strategy (configuration files, > autowiring, PHP code...) that makes it worthwhile. What we are trying here > is to find an additional *shared* way of putting things into a container > specifically for package authors. Because it's almost impossible for > package authors to write a bridge for every framework out there). > > > > Also, since FIG 3.0 has passed, it's time that we officially create a > working group. > > > As a reminder, we (the container-interop participants) explored several > strategies: > > > - unified file format > > - common interfaces for container definitions > > - common interfaces for dumping PHP code representing container definitions > > - service providers > > > I have summarized this in those 2 blog posts: > https://www.thecodingmachine.com/psr-11-an-overview-of-interoperable-php-modules/ > > and > https://www.thecodingmachine.com/psr-11-get-ready-for-universal-service-providers/ > > . > > > The conclusion we reached was that standardized service providers are the > way to go. Among many criteria, they are easy to write, and if done right, > can be properly optimized by compiled containers. > > > We started working on it at > https://github.com/container-interop/service-provider/ > > > Work is well advanced: we have prototype integrations available with the > major frameworks out there. > > > There is still a lot of work to be done: > > > - Recently, Rasmus Schultz came up with an alternative proposal. The idea > is that rather than trying to provide factories to the containers (what > service providers do), a module could provide its own container and publish > to the "main container" the list of entries it contains. Rasmus detailed > the idea here: > https://github.com/container-interop/service-provider/issues/40 . This > idea looks a bit like the "delegate lookup feature" that was removed from > PSR-11 in the philosophy (several containers running side-by-side), but is > different in the implementation. I'd be interested to gather feedback from > the community on Rasmus' proposal (I suspect it might be complementary to > container-interop/service-provider rather than opposite) > > - With the current proposal, we can already add services and extend > existing services. We need to know if we want to be able to do more (like > adding/extending services conditionally based on the container's > configuration). More generally, we need to discuss the exact scope of the > PSR (limited to simple use cases? extended?) > > - Finally, there will be a huge amount of work waiting for us in the > nitty-gritty (exceptions handling, etc...) > > > I'm hereby calling *interested members to step up* to create a working > group, and for member projects to give as much feedback as possible. PSR-11 > has made a big leap forward in the very last days because "big players" > joined the party a bit late :). For this PSR, it would be great to have > some feedback from you guys early on in the process. > > > ++ > > David. > > Twitter: @david_negrier > > Github: @moufmouf > -- 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/d23084d7-67c0-44e8-a770-d52c366f5187%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
