Not sure why "bootstrapping everything into one container" keeps coming up again and again, as I seem to have described a solution which involves multiple containers. Of course, for this to work some sort of lookup delegation has to be in place.
With regard to "sharing the same namespace", that's true. Especially true in an environment like a CMS, where you expect many plugins in one system to provide services while being ignorant of other plugins' services. For this reason, we prefix the services which are scoped to specifically the plugin, or the plugin's extension. Internally, we have a method often called `_p()` which prefixes a service ID with something that is configured on the service provider. So, when we want to scope something to the particular plugin, or we want to retrieved something scoped to the plugin from its service provider, we pass the key through that method first; otherwise, if we want something that is globally scoped, e.g. WP's DB connection, we don't use that method. Maybe by optimizing and formalizing this approach it could be possible to solve the issue of namespaces. As for cases where one team doesn't know what another team is doing - maybe they are different teams in the same organisation, or independent extension developers - I don't feel that this is a problem. Teams that work in the same organisation simply need to coordinate their effort if they are working on adjacent/overlapping areas, such as decide who has authority to develop the database-related services in a period of time. In any case, generally, when you consume some API, you need to know about that API. You don't go invoking/declaring random functions and instantiating/declaring random classes willy-nilly; instead, you research what the available API is. Same thing here: if you are consuming services provided by somebody, you research what they provide. Otherwise, you run into a conflict, which has to be resolved, and that's OK. It's the same thing with functions and classes. I don't believe that the mechanism of conflict resolution is in the scope of a service provider standard. 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/7b9b1593-ca16-488e-ac50-544cfcb42941%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
