[PSR-11] Question about PSR-11

[Pedro Cordeiro]

I tried searching but couldn't find the reason PSR-11 doesn't have a `register`, `add` or similar method to register a new service in the container.

I'm not sure if I misunderstood something, but it looks like I'll still have to create a new contract wrapper around PSR-11 to define how to register new services to the container, and then I'll have to make a bridge for each provider, since they won't agree on how to add new services. Wouldn't it defeat the purpose of this PSR, which is interoperability?

[Stefano Torresi]

Check the meta doc:
https://github.com/php-fig/fig-standards/blob/master/proposed/container-meta.md#3-scope

Il giorno lun 3 ott 2016 alle ore 19:34 Pedro Cordeiro <pedro...@gmail.com> ha scritto:

I tried searching but couldn't find the reason PSR-11 doesn't have a `register`, `add` or similar method to register a new service in the container.

I'm not sure if I misunderstood something, but it looks like I'll still have to create a new contract wrapper around PSR-11 to define how to register new services to the container, and then I'll have to make a bridge for each provider, since they won't agree on how to add new services. Wouldn't it defeat the purpose of this PSR, which is interoperability?

--
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+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/1877a319-8b9e-4150-8048-97e6b43750ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Pedro Cordeiro]

Thanks. I think I missed that.

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'...?

Was this discussed? Anyone have a link for the discussion? Search tool here in googlegroups didn't help me much.

Thanks again and sorry if I'm missing something.

[Pedro Cordeiro]

After some more research, I found a very passionate discussion about this on github.

Thanks.

[Matthew Weier O'Phinney]

On Mon, Oct 3, 2016 at 12:54 PM, Pedro Cordeiro <pedro...@gmail.com> wrote:
> Thanks. I think I missed that.
>
> 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'...?

Adding services is usually done at the application level, at which
point you've chosen an implementation.

The part where it gets interesting is when writing a package that may
provide services, and thus potentially configuration or factories for
use with a container. That aspect is also being discussed by
container-interop, under the projects definition-interop and
service-providers (look for those repos under the container-interop
organization on github), with the latter looking like the likely
approach. Once an approach is vetted, the container-interop group will
bring that proposal to FIG as well.

The 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. Some containers, like Disco and php-di,
are almost entirely reflection and/or annotation driven, meaning
they're highly automated. Others, like Pimple and zend-servicemanager,
rely on factories in order to generate services. Some, such as Pimple
and zend-servicemanager, provide the abiliity to "extend" a service
(essentially decorating any existing factories in order to add
pre-conditions or perform further initialization tasks once an
instance is obtained). Still others provide fallback mechanisms
(abstract factories in zend-servicemanager). Determining what the
minimum set of features to support is proving to be quite difficult!

In the meantime, PSR-11 is already useful. Since you can define the
container during bootstrapping of your application, if your
application supports PSR-11, you pass it the container, and all it
should be doing is calling one or the other of has or get, typically
in order to pull something such as a controller or middleware, and all
related dependencies.

By the way, if you're interested in one approach to the "adding
services to disparate container implementations" problem, we tackled
it in the zend-expressive-skeleton. We're also evaluating an approach
we call "config providers" that is not dissimilar to the way
service-providers works, which should allow us to help vet that
approach for viability.

> https://groups.google.com/d/msgid/php-fig/47bcf0c9-16e2-46f7-bf41-c728e02adf45%40googlegroups.com.

>
> For more options, visit https://groups.google.com/d/optout.

--
Matthew Weier O'Phinney
mweiero...@gmail.com
https://mwop.net/

[Sara Golemon]

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

[David Négrier]

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

[Sara Golemon]

On Tuesday, October 4, 2016 at 3:11:26 AM UTC-7, David Négrier wrote:

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)

Thanks for the history link. Good read, and I'm glad so many voices were in that discussion.  I've no need to reopen the bike shed, and honestly namespaces afford us the ability to have slightly conflicty names if it ever came to that.  My $0.02USD is that it should have DI in the name (i.e. DIContainer), but I'm not fussed at all, really. Don't mind me.

 

> 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?

True, and perfect being the enemy of good, there's no need to over-engineer what is ultimately a simple solution to the issue.

If it looks useful to propose a generic container interface, we can easily avoid the conflict by calling them Collections instead.  Sorted.

-Sara

[Stefano Torresi]

Il giorno mer 5 ott 2016 alle ore 01:13 Sara Golemon <p...@golemon.com> ha scritto:

My $0.02USD is that it should have DI in the name (i.e. DIContainer)

100% agree, but I guess this ship has sailed... ;-)

It occurs to my mind that, while most of the development of container-interop happened outside this list - so FIG members and bystanders may have not been involved as much as they could - on the other hand the editors have had the care to post regular updates here, with links to github, so anybody potentially interested has been given the chance to chime in.

[Woody Gilk]

Why should a class name contain information that is present in the class namespace? If you don't like the class name, there is the option to apply a "use ... as ..." alias.

--
Woody Gilk
http://about.me/shadowhand

--

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+unsubscribe@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAFojS1u6WEqGRr4i91vTSd5ohyMfuieqFySA8GsvPpaKr6NkhA%40mail.gmail.com.

[Daniel Plainview]

What do you mean? The namespace is simple "Psr\Container". It doesn't clarify domain.

On Wednesday, October 5, 2016 at 5:19:40 AM UTC+3, Woody Gilk wrote:

Why should a class name contain information that is present in the class namespace? If you don't like the class name, there is the option to apply a "use ... as ..." alias.

--
Woody Gilk
http://about.me/shadowhand

On Tue, Oct 4, 2016 at 7:26 PM, Stefano Torresi <ste...@torresi.io> wrote:

Il giorno mer 5 ott 2016 alle ore 01:13 Sara Golemon <p...@golemon.com> ha scritto:

My $0.02USD is that it should have DI in the name (i.e. DIContainer)

100% agree, but I guess this ship has sailed... ;-)

It occurs to my mind that, while most of the development of container-interop happened outside this list - so FIG members and bystanders may have not been involved as much as they could - on the other hand the editors have had the care to post regular updates here, with links to github, so anybody potentially interested has been given the chance to chime in.

--
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+u...@googlegroups.com.

[Larry Garfield]

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.

--Larry Garfield

[Matthieu Napoli]

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

[Pedro Cordeiro]

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.

[Daniel Hunsaker]

On Thursday, October 6, 2016 at 12:46:28 PM UTC-6, Pedro Cordeiro wrote:

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.

On the bright side, there's a "yet" attached to that "still".  :)

 

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.

We've all read through things too fast to catch the details we're looking for.  Nothing wrong with being human.  :)