Hey Sara, Actually, the name of the interface was the first issue we discussed when starting container-interop (the test-bed for PSR-11).
You can have a look at the Github issue that explains why we ended up with ContainerInterface here: https://github.com/container-interop/container-interop/issues/1 (and the results of the vote here: https://github.com/container-interop/container-interop/wiki/%231-interface-name:-Vote) > I think the impedance mismatch here is that PSR-11 isn't about generic Containers, but rather about a specialization of Containers aimed at dependency injection. Interesting. I think it is the first time this issue is raised. We use the term "Container" as a diminutive for "Dependency Injection Container" (because PSR-11 is definitely about DI containers). I think in the PHP world, the term Container mostly refer to DI containers (rather than the more general datastructure), but I might be wrong. Well, naming is hard! If you have a better alternative for the name, please feel free to make a suggestion, but we have been a lot to discuss about it and so far, and "ContainerInterface" has the very large majority of supporting votes. > Further, it strikes me as more useful to have that generic container implementation in place, then define a DI model based around it, since the containers presented here are obviously Map specializations. Indeed, this is a specialization of a Map, but if we ever need an interface to describe a map, well... we could name it MapInterface, couldn't we? -David Le lundi 3 octobre 2016 23:06:06 UTC+2, Sara Golemon a écrit : > > On Monday, October 3, 2016 at 10:54:30 AM UTC-7, Pedro Cordeiro wrote: >> >> Anyway, how do I prepare my application to have interoperable containers, >> since they don't agree on how to add new services? I will have to write >> adapters for each specific implementation... doesn't that defeat the >> purpose of the PSR? Shouldn't "adding services" be in-scope, rather than >> 'let some implementations rely on autowiring, others have specific methods >> for registering'...? >> >>> > I think the impedance mismatch here is that PSR-11 isn't about generic > Containers, but rather about a specialization of Containers aimed at > dependency injection. From that point of view, I think the has/get > limitation makes more sense, but I personally would like to see the > interfaces named in a way which more precisely reflects that use case > scenario so that we leave the door more open to generic container > interfaces (e.g. Vector, Set, Map type containers). Further, it strikes me > as more useful to have that generic container implementation in place, then > define a DI model based around it, since the containers presented here are > obviously Map specializations. > > -Sara > -- 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/93db7065-67d8-4cb9-822c-32345bb6f87d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
