I understand the reasoning now. It saddens me a little (as an end user) that I still won't be able to have truly agnostic implementations that depend on a container (because I need to set the entries, after all, so I'll need adapters for each specific implementation), but I understand that under FIG 2.0, the purpose is to facilitate interoperability between the frameworks themselves, and the current scope decision makes sense under that philosophy.
The metadoc is complete enough, indeed. I'm the one to blame here, my initial skimming of the documentation for PSR11 missed the section about the scope and the link to the relevant discussion. Thanks for the responses. Em quinta-feira, 6 de outubro de 2016 13:23:11 UTC-3, Matthieu Napoli escreveu: > > > Given that most of PSR-11 was developed "off in a corner" from a FIG POV, >> I'd strongly suggest that anything people ask about here be taken as a need >> for clarification in the metadoc (if something isn't there already). "This >> GitHub link in this other group you wouldn't know to look for" is a useless >> answer when (not if) questions arise from people reading the spec in the >> future after passage. >> > > Hi Larry, I agree very strongly with that remark, in fact we take that > quite seriously :p (as you can see by the length of the meta document) > Everyone can find all that information and all those links there: > > - > https://github.com/php-fig/fig-standards/blob/master/proposed/container-meta.md#5-history > - > https://github.com/php-fig/fig-standards/blob/master/proposed/container-meta.md#6-interface-name > - > https://github.com/php-fig/fig-standards/blob/master/proposed/container-meta.md#11-relevant-links > > Regarding the original question this is answered in the document too: > https://github.com/php-fig/fig-standards/blob/master/proposed/container-meta.md#31-goals > > It is important to distinguish the two usages of a container: >> >> - configuring entries >> >> >> - fetching entries >> >> Most of the time, those two sides are not used by the same party. While >> it is often end users who tend to configure entries, it is generally the >> framework that fetches entries to build the application. >> This is why this interface focuses only on how entries can be fetched >> from a container. > > > Any kind of improvement in the wording is welcome. I have taken a few > sentences from Matthew's response and reworded it a bit, maybe we could add > in this section: > > > Another reason the idea of "adding services" is being considered > separately is because there's a ton of approaches, and not a lot > of commonalities between them. Determining what the minimum set of features > to support is proving to be quite difficult, and as such is being worked > upon in a separate PSR. > > > In the meantime, PSR-11 is useful on its own. Containers can be > configured by the end users, with their custom API. Then PSR-11 containers > can be provided to compatible applications which will call get() or has() > to retrieve objects such as a controllers, middlewares, and all their > related dependencies. > > Thoughts? > > Matthieu > -- 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/2d649b22-50e2-4a28-8401-627bfeb94fc6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
