ContainerInterface name

[moufmouf]

So far, we have chosen to call the main interface ReadableContainerInterface.
The rational behind it is that "ContainerInterface" might be too generic.

We thought about "SimpleContainerInterface" but deemed it was too generic.

This thread is open to add new suggestions.

So far, I have just started looking at other languages.

Spring (in the Java world) has a "BeanFactory" interface, with a "getBean" method.

Add other suggestions (or what other frameworks do below)

---

Edit:

• summary of options: https://github.com/container-interop/container-interop/wiki/ContainerInterface-name
• vote: https://github.com/container-interop/container-interop/wiki/%231-interface-name:-Vote

[moufmouf]

In the Java world, we also have the javax.inject namespace defined by JSR330.

It defines a Provider interface: http://atinject.googlecode.com/svn/trunk/javadoc/javax/inject/Provider.html
Although it is different from our ReadableContainerInterface interface, the "Provider" word is interesting (it denotes it can give the user something)

[mnapoli]

Yes interesting, something like ServiceProvider, but without Service because a container may contain other things.

However it's really not close to the usual language of dependency injection and containers in PHP. I've never seen that word in that context before.

[mnapoli]

Summary of current options:

• ContainerInterface
• SimpleContainerInterface
• ReadableContainerInterface
• ServiceLocatorInterface
• ServiceProviderInterface
• ProviderInterface

[taylorotwell]

My vote would be ServiceLocatorInterface. Has some precedence in other ecosystems: http://msdn.microsoft.com/en-us/library/microsoft.practices.servicelocation.iservicelocator_methods(v=pandp.51).aspx

[AmyStephen]

Personally, I'd go with ReadableContainerInterface or ReadContainerInterface or RetrieveServiceInterface (or, I'd add the set and delete methods and call it a ContainerInterface ;-) ...).

@taylorotwell I noticed MS "retired" that content. Wonder if they have moved away from calling it such?

To me, a ServiceLocator is more of a verb, than a noun. Take a knife as an example. A knife can be used as a weapon or it could be for cutting food. It's the same object -- how it's used is what makes the difference.

I know that is a strange example, but that's how I look at service location. The container is the same if dependencies are injected into a class, or a class uses the container to "pull dependencies in."

The container behaves no differently and the Interface is the same. For that reason, I would shy away from naming an Interface after usage. Might be better for the name to focus on the Container's job.

[moufmouf]

Hi,

I agree with Amy about the ServiceLocator name. Actually, I would vote against the term "Service" because that interface can serve more than services.

If you call the interface ServiceContainer or ServiceLocator, you are implying that the interface will be used to fetch services (like a Logger, a Cache, a Controller or a DatabaseConnection). This is what most people out there are doing. Bu not all of us. For instance in Mouf (http://mouf-php.com/), I'm can inject pretty much anything in a controller (a datagrid, a SQL request, an object representing an HTML form with all its fields, etc...) These objects I'm injecting do not qualify as "services" and yet, they are fetched from the container. My point is the same as Amy's: we don't want to be too specific on this one.

[mnapoli]

Related: http://paul-m-jones.com/archives/5853

What differentiate a SL and a DI Container is how they are used. So I'd agree with Paul Jones and use the generic name Container to avoid the restrictive name of ServiceLocator. Because that interface can be applied to a DI container, and type-hinting against ServiceLocator for DI container is pretty confusing.

However it's totally possible to use a Container as a ServiceLocator, so my conclusion would be: use a name that contains Container.

(or, I'd add the set and delete methods and call it a ContainerInterface ;-) ...).

@AmyStephen every container has a different way of defining entries. That's a very hard thing to standardize. And that's not needed for basic container interoperability like replacing an implementation by another, or chaining. So let's keep that for another future interface.

@moufmouf Agreed, using Service in the name is too restrictive. Another example: get("db.host") could return a "parameter"/value. So Service is too restrictive here if we are talking about a "Container" that just contains "things".

[shochdoerfer]

+1 for not sticking with the term "Service". Service is way too generic and too many people have a completely different understanding what a service should be.

I am also not that happy with ReadableContainerInterface, I am not sure if we really need to "mark" the interface being read-only and since we return objects we can indeed change their state (if the container returns singleton instances). So the name might imply something that is not true or at least can be misunderstood.

I just had a look how the Spring Framework guys named their interface. It`s called IBeanFactory, also pretty generic and sort of straight to the point. If you look closely the interface is a factory, the implementation of the interface is what it turns it into a DIC or a service locator or whatever. So as a conclusion I think I would mostly prefer the ContainerInterface.

[AmyStephen]

@moufmouf - Glad to hear of your experiences as I also use the container in much the same way, storing class instances and data. Not all dependencies are class instances so having other values in the container is very helpful.

I agree with everything @shochdoerfer said. The only problem is, if it's named ContainerInterface, then we are back to needing to have the other basic methods.

Earlier, someone mentioned separation of concerns as a reason to have the get and has methods separated from the set and remove. IMHO, separation of concerns is better served separating the actual creation of the class instance (which I would class as a function of the service provider, not the container). The interface for the Container itself is nothing more than getting and setting and removing values from the container.

The challenge might be in standardizing how service providers operate but it should be pretty straightforward to agree on the basic CRUD-like operations of the container and the signature of those methods.

[mnapoli]

Rather than separation of concerns, it's more a question of interface segregation principle (the I from SOLID).

no client should be forced to depend on methods it does not use

Frameworks getting entries from the container do not necessarily need to put entries in it. Actually, the current ReadableContainerInterface has enough methods to be used as it is. Adding set methods would be useless for the kind of usage we are trying to write an interface for.

And of course, it would be very complex. I'm ok to start thinking at a way to define container entries (a set method), but in a separate interface. There's no need for this method here. For example, Acclimate or other Symfony/Silex adapters work very well without those methods.

[AmyStephen]

On Sun, Dec 22, 2013 at 10:12 AM, Matthieu Napoli
notifications@github.comwrote:

Rather than separation of concerns, it's more a question of interface
segregation principle
http://en.wikipedia.org/wiki/Interface_segregation_principle (the I
from SOLID).

no client should be forced to depend on methods it does not use

Makes sense, sorry about that.

Frameworks getting entries from the container do not necessarily need to
put entries in it. Actually, the current ReadableContainerInterface has
enough methods to be used as it is. Adding set methods would be useless
for the kind of usage we are trying to write an interface for.

OK, but when a class only retrieves data from the container but does not
populate the container, it's definitely being used as a Service Locator.

And of course, it would be very complex. I'm ok to start thinking at a way
to define container entries (a set method), but in a separate interface.
There's no need for this method here. For example, Acclimate or other
Symfony/Silex adapters work very well without those methods.

Both examples of usage of Service Locators.

Starting to agree with @taylorotwell that the Interface should be named
ServiceLocatorInterface

[taylorotwell]

The interface segregation principle has more to do with not forcing implentors to implement methods they don't need. I don't think it really applies to this discussion that much since most definitely all containers offer both read and write.

Anyways, to get away from bike shedding, this argument has largely been solved in many other ecosystems and we shouldn't delve into a huge "not invented here" syndrome with every PHP interop discussion.
—
Sent from Mailbox for iPhone

On Sun, Dec 22, 2013 at 10:20 AM, AmyStephen notifications@github.com
wrote:

On Sun, Dec 22, 2013 at 10:12 AM, Matthieu Napoli
notifications@github.comwrote:

Rather than separation of concerns, it's more a question of interface
segregation principle
http://en.wikipedia.org/wiki/Interface_segregation_principle (the I
from SOLID).

no client should be forced to depend on methods it does not use

Makes sense, sorry about that.
Frameworks getting entries from the container do not necessarily need to
put entries in it. Actually, the current ReadableContainerInterface has
enough methods to be used as it is. Adding set methods would be useless
for the kind of usage we are trying to write an interface for.

OK, but when a class only retrieves data from the container but does not
populate the container, it's definitely being used as a Service Locator.
And of course, it would be very complex. I'm ok to start thinking at a way
to define container entries (a set method), but in a separate interface.
There's no need for this method here. For example, Acclimate or other
Symfony/Silex adapters work very well without those methods.

Both examples of usage of Service Locators.
Starting to agree with @taylorotwell that the Interface should be named

ServiceLocatorInterface

Reply to this email directly or view it on GitHub:
#1 (comment)

[mnapoli]

Just as a side note: would everyone involved here be OK to make a final decision on that subject in january? Given all the holidays and so, I figure it's better to not rush it since we might all not be able to follow everything.

Regarding the name, even though I disagree I still think the discussions are sane and interesting. And about NIH:

• Microsoft IServiceLocator seems to have actually been replaced by IServiceProvider
• Spring interface is BeanFactory
• Spring .Net interface is IObjectFactory

I don't see a de facto solution.

But for me, this interface could be named BakedPotatoesGeneratorInterface I would still use it :) This is not a PSR, this is 1) interoperability and 2) testing out an interface in real life for a future PSR.

And it has been said, but having Service in the name is a bad idea IMO (ProviderInterface or LocatorInterface look a bit better).

[AmyStephen]

@mnapoli I will also use BakedPotatoesGeneratorInterface -- don't want to get into bike shedding, so, appreciate the reminder from @taylorotwell

Good to set a date, January makes sense -- maybe folks would be willing to describe the larger picture of how service providers, services, and containers fit together. I tend to disagree that we should avoid service because I think we should define it. But, before we can do so it's worth spending time reflecting on the terms and sharing something more substantial than a gut reaction to someone's comments.

Having said that, in the end, I've got no problem adopting the potato interface. Interoperability is the goal.

[shochdoerfer]

January is fine for me. We should take the time which is needed for the final decision. Or at least the time needed to let me convince you that "BakedPotatoesGeneratorInterface" is not the right choice ;)

[Ocramius]

I don't see a use case for standardization of a "writable" container interface. That's really something tightly coupled with how the framework/user wants to code his own DIC stuff, and I don't see any space for standardization there.

I'd rather go with LocatorInterface.

Why?

• doesn't define that what you get is a "service"
• doesn't assume that what is returned is constant for the same passed in values
• only assumes that you can "find" something or see if something "is there"
• denies the idea that the object actually "contains" something. Who said that a service locator is also a container?

class LocatorInterface
{
    public function get($request);
    public function has($request);
}

That's my idea for it so far

[AmyStephen]

+1 @Ocramius

[moufmouf]

I pretty much like the LocatorInterface for all the reasons given by @Ocramius.
Anyway, the fact that someone comes up with a new interesting name at that point in the discussion shows that we can still take some time to think about it.
I completely agree to wait till January before taking a decision.

[taylorotwell]

I like @Ocramius's proposal fine. Though, as I voiced in another thread, choosing method names by selecting the most popular method names used among containers is the exact opposite approach we should be using.

[shochdoerfer]

Was thinking about this over and over again. I am still not yet that happy with the suggestions. I do not like the name LocatorInterface as for me it implies at the implementation is "locating" an object which is not what`s really happening. To me this sounds like the implementation is about searching for the requested object. What is really happening is that the implementation of the interface creates objects or manages object instances. For that reason I would prefer either ObjectFactory as mentioned before or ObjectStore. For the latter @AmyStephen might probably argue that we need writeable methods again ;)

[Ocramius]

@shochdoerfer what about configs and scalars that may come from the locator (not values, constants)?

Also, no, I don't want to force write access on implementations. I also don't see how that would increase interoperability: a ZF2 app does not write services into the SF2 or Silex containers, and the opposite wouldn't happen either.

[AmyStephen]

Agree again w @Ocramius, a get request of the container might be for data other than class instances, still prefer LocatorInterface as suggested by @mnapoli and @Ocramius

[jeremeamia]

I do not like the name LocatorInterface as for me it implies at the implementation is "locating" an object which is not what`s really happening. To me this sounds like the implementation is about searching for the requested object. What is really happening is that the implementation of the interface creates objects or manages object instances. For that reason I would prefer either ObjectFactory as mentioned before or ObjectStore.

Nope. We shouldn't imply that the container-thingy has to create anything or that the things have to be objects.

I'd rather go with LocatorInterface.

Why?

doesn't define that what you get is a "service"
doesn't assume that what is returned is constant for the same passed in values
only assumes that you can "find" something or see if something "is there"
denies the idea that the object actually "contains" something. Who said that a service locator is also a container?

Good points, especially the "denies the idea that the object actually 'contains' something". I think LocatorInterface makes sense, but I'm afraid that it will scare DIC implementors away.

I think ProviderInterface also fits, but I still like ContainerInterface, because "Container" seems to be the only term that commonly represents the things that the interface is being written for. I don't think we need the Readable prefix either, since we will A.) probably never have a writable container interface –or– B.) we can use a "Writable" prefix on that one if it does happen.

[mnapoli]

Hey all, thanks @jeremeamia for re-viving this thread after the holidays. I especially agree with what you said.

It seems we are moving forward. I set up a quick summary of the options (and opinions expressed) in the wiki: https://github.com/container-interop/container-interop/wiki/ContainerInterface-name Please note this is not a vote, this is just to try to see where we are after all these discussions.

Before you jump at me ;) :

• I tried to make a "useful" summary, i.e. listing only options that were really discussed (skipping names just evoked once)
• I put done only "strong" opinions expressed in the discussion, and I may have misinterpreted somethingw. Keep in mind I only tried to be helpful, and if I made you say something you disagree:
• please edit the document to correct and complete it

(given this is the wiki, everyone should have write access)

Just a side-note to express my -1: anything with "Object" or "Service" in the name

[Ocramius]

I'm afraid that it will scare DIC implementors away.

We're not working on DIC here - this is service location. Standardizing DIC is way out of scope for now, given that there's not even a single container out there that has anything in common with the others (at least from what I know, and I worked with a lot of 'em). There's no DIC people here, only locators so far.

Container is a no-go. If my object produces non-shared instances then it's not a container. It does not contain stuff.

[shochdoerfer]

We're not working on DIC here - this is service location.

Really? Was not aware of that. At least in the projects` README.md it is stated that the project "tries to bring interoperability between DI containers" Should that be changed then?

There's no DIC people here, only locators so far.

Does that mean I have to leave for now?

[Ocramius]

Does that mean I have to leave for now?

@shochdoerfer ofc not :D

I just think it makes little sense to standardize something for which I didn't see a "simil-silver-bullet" around yet.
Yes, this issue is about standardizing a service locator, not a dic.

And yes, that's as far as we can go without creating something bloated :P

[mnapoli]

@Ocramius like @shochdoerfer I'm a bit confused about what you said. Is that what you are trying to say:

we are trying to standardize the "service locator" use case so that we can use it for DI container (or SL, or whatever) interoperability

We still have to keep in mind that everybody's goal here is container interoperability, not SL standardization.

Thanks to the discussion, I'm beginning to like LocatorInterface. If we look at it from who will use it:

• DIC implementors: they have to understand that the DIC is used as a SL at some point (by the front controller usually). And what we are standardizing is this usage (SL), so LocatorInterface makes sense here.
• end-users: the only case would be the (bad) case where they inject the whole container, for example in their controller. That is definitely the use-case of a SL. So it may as well be a DIC, it's still used as a SL.

class MyController {
    public function __construct(LocatorInterface $locator) {
        $this->locator = $locator;
    }
    // ...
}

Here LocatorInterface makes sense. It means: give me anything that can "locate" things. It turns out a DIC will be injected, but it doesn't matter what it really is, the only thing that matters is what it can do (and Larry explained it nicely here: http://www.garfieldtech.com/blog/beyond-abstract).

[taylorotwell]

A dependency injection container (DIC) and a service locator are the exact same thing. Only in PHP have I ever seen arguments that they are somehow different.

[Ocramius]

Still contains stuff, and still is redundant: the only interfaces I saw not
being "consumable" are markers. What's the point in a non-consumer one?
On 10 Jan 2014 11:42, "Matthieu Napoli" notifications@github.com wrote:

I'm not especially fond of that option (even though I see the rationale
behind it) bc when you take ConsumerInterface out of this context, you
expect the object to consume things (not provide, or locate).

Actually, just thought about this a bit more and maybe
ConsumableContainerInterface would be a better alternative?

I'd find this option a bit nicer than ReadableContainerInterface and more
explicit than just ContainerInterface. Maybe this could be a compromise
with LocatorInterface too?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-32017620
.

[mnapoli]

Those were nice 5 days without emails :), maybe it's time to get to a vote?

That raises several questions:

• who can vote? I'd say everyone that participated in this thread to avoid unwanted weird scenarios
• where can we vote? A wiki page could do the job
• how can we vote? Voting for only one solution would be a mistake IMO, given there are several valid options and the best solution would be to find a compromise.

I'd suggest to use a range voting: rate each option with either:

• 0, 1 or 2
• or -1, 0 or +1 (just like the poll we did in the wiki)

Then we add the points and voilà.

[shochdoerfer]

@mnapoli I am fine with that procedure.

[moufmouf]

I definitely agree with range voting. Maybe we could even extend the range.

• 0 to 10 would allow everyone to express precise opinions about each option
• -2 to 2 would allow to express a strong preference (+2), a minor preference (+1), indifference (0) a minor or strong dislike (-1 and -2 respectively)

Anyway, extending the range can be more complex to voters, and if there are people preferring to stay with -1, 0, +1, I'll be glad to go with that range.
As long as we can get a vote and a decision, I'll be very happy :)

[AmyStephen]

Voting is fine, but does anyone really disagree with ContainerInterface
now?

Given the discussion of what the get and has is intended to do, I'm
perfectly comfortable with that name.

On Sun, Jan 19, 2014 at 11:28 AM, David Négrier notifications@github.comwrote:

I definitely agree with range voting. Maybe we could even extend the range.

• 0 to 10 would allow everyone to express precise opinions about each
  option
• -2 to 2 would allow to express a strong preference (+2), a minor
  preference (+1), indifference (0) a minor or strong dislike (-1 and -2
  respectively)

Anyway, extending the range can be more complex to voters, and if there
are people preferring to stay with -1, 0, +1, I'll be glad to go with that
range.
As long as we can get a vote and a decision, I'll be very happy :)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-32713811
.

[Ocramius]

Yeap, I disagree with Container :-)

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

On 19 January 2014 19:14, AmyStephen notifications@github.com wrote:

Voting is fine, but does anyone really disagree with ContainerInterface
now?

Given the discussion of what the get and has is intended to do, I'm
perfectly comfortable with that name.

On Sun, Jan 19, 2014 at 11:28 AM, David Négrier notifications@github.comwrote:

I definitely agree with range voting. Maybe we could even extend the
range.

• 0 to 10 would allow everyone to express precise opinions about each
  option
• -2 to 2 would allow to express a strong preference (+2), a minor
  preference (+1), indifference (0) a minor or strong dislike (-1 and -2
  respectively)

Anyway, extending the range can be more complex to voters, and if there
are people preferring to stay with -1, 0, +1, I'll be glad to go with
that
range.
As long as we can get a vote and a decision, I'll be very happy :)

—
Reply to this email directly or view it on GitHub<
https://github.com/container-interop/container-interop/issues/1#issuecomment-32713811>

.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-32715154
.

[moufmouf]

@AmyStephen: indeed, it is likely that ContainerInterface will be the way to go. My understanding is that all propositions have received critics but ContainerInterface is only strongly opposed by Marco so far, while most of the other members of this discussion think this is maybe not optimal, but mostly ok.

However, the wiki page clearly states "this is not a vote". Therefore, I would feel inconfortable turning that wiki page into a decision. Especially, I don't want anyone to fill bad about it.

So a vote might be the best way to avoid trouble. Also, if we arrive to push this far enough, we will certainly have the chance to discuss once more the naming of that interface on the FIG mailing list, for a PSR :)

[mnapoli]

I agree that a vote is sane :)

@moufmouf I'd rather stay with a simpler vote format (-1/0/+1) if that's ok with you? That would be consistent with the poll and simpler to vote.

[moufmouf]

@mnapoli Ok for staying with (-1/0/+1). This was just a proposition, and as long as we get the vote done, I'll be more than happy.

Shall we get the vote started now? Where should we vote? In this thread? In a dedicated app/website?

[mnapoli]

OK vote started, I suggest to open it for 2 weeks (like the FIG IIRC). I used the wiki like for the poll, at least everyone has read/write access and we can keep the discussion out of it.

Link: https://github.com/container-interop/container-interop/wiki/%231-interface-name:-Vote

Please cast your votes ;)

[philipobenito]

Came to the discussion pretty late, had a read through comments and added my vote to the wiki as requested.

[mnapoli]

@happyaccidents I am sorry to say that but the vote is limited to people having participated in the discussion before it started :/ I wish it where otherwise because I know your interest on the subject, but I believe we have to stand by what was said to keep things proper, and avoid exceptions potentially leading to other exceptions (where would be the limit).

[philipobenito]

@mnapoli that's fine, only just read your tweet to join so my fault, not a problem

[dongilbert]

@mnapoli Do we need to keep the vote open until Feb 3, even though (I think) everyone who participated previously has now added their vote to the wiki page?

[mnapoli]

@dongilbert I checked, everybody voted, I see no reason to wait unless someone wants to change his mind? So it looks like ContainerInterface is the final name!

@happyaccidents thanks

[mnapoli]

Here is the detailed result, which shows ContainerInterface is a good compromise:

• ContainerInterface: +8
• ProviderInterface: +2
• LocatorInterface: 0
• ReadableContainerInterface: -5
• ServiceLocatorInterface: -6
• ObjectFactory: -6
• ObjectStore: -8
• ConsumerInterface: -9

[mnapoli]

I have renamed the interface: https://github.com/container-interop/container-interop/blob/master/src/Interop/Container/ContainerInterface.php

Thank you everyone who participated! The discussion was definitely constructive and not unnecessary, I'm glad we came to a reasonable compromise.

Now to be tagging a v1.0 with ContainerInterface, there are only 2 small points left (not the same amount of discussion than here I guess):

• Adding a getIdentifier method in the NotFoundException interface #3 Adding a method on the NotFoundException (on which this interface depends)
• Method names are too generic. #6 Method names (maybe this whole discussion and decision will have solved that issue)

I invite you all to check out those issues. I'll close this one!

[Ocramius]

@mnapoli can you rename the milestone? :)

[mnapoli]

@Ocramius done :)

[J7mbo]

Why is this still being called a container?

[mnapoli]

@J7mbo https://github.com/container-interop/container-interop/wiki/%231-interface-name:-Vote

Let's not reopen that discussion as it has already been a lengthy one finished a year ago. You can re-read the whole thread if you want to understand people's opinions.

See also the meta-document: https://github.com/container-interop/container-interop/blob/master/docs/ContainerInterface-meta.md#interface-name

[moufmouf]

@J7mbo This issue has been closed for 1 year now. Regarding container-interop, the ContainerInterface name is settled, as a stable release has been made. The choice of the name has been extensively documented in this thread and in the meta document.

Now, we are trying to move container-interop to the PHP-FIG (https://groups.google.com/forum/#!forum/php-fig), so of course, we can discuss naming of the interface of the soon-to-come PSR. I would prefer if you ask this question on the PHP-FIG mailing list rather than in this thread that should remain closed.

Of course, the ContainerInterface name is the result of several months of discussion and I think the name that was chosen has been done wisely, through a lot of discussion and a vote, so I'm ready to defend it.

[J7mbo]

@moufmouf Actually I'd prefer to be in a discussion: Please don't assume that I'm out for an aggressive attack that you have to 'defend' against. I think ContainerInterface goes well with Symfony devs, and their style of coding, because they love putting "Interface" at the end of everything. But I wholeheartedly disagree with "Container".

The reasons for that are that a container implies something that holds objects - if you place objects in this box, you're already advocating the service locator pattern and creating a god object. Let's not even get onto how Laravel names things. Call it a container and we're really not progressing in teaching best practice to the PHP community - which is what FIG is supposed to be standing up for.

It should be Injector imho, however the decision has already been made.

[Ocramius]

think ContainerInterface goes well with Symfony devs, and their style of coding, because they love putting "Interface" at the end of everything.

To be honest, most of the people that discussed in this thread have little to do with Symfony anyway.

you're already advocating the service locator pattern and creating a god object

Yes, we are. The fact is that the only possible interface for an Injector or a DIC or a Container is indeed a locator. Even in "higher level" libraries having a single location where the injector is used, SL is how this is achieved (see, for example, $app = $injector->get('app'), and no other usage of $injector - yes, that's SL, get over it).

Additionally, an interface without has and get is pretty much useless for the purposes of interoperability (we are trying to build homogeneous APIs that interact with each other).

we're really not progressing in teaching best practice to the PHP community

I actually agree with that, but a vote has already been set for the name, even if I disagree with it. From now on it's either accept or reject the proposal for it, and we may reconsider naming if the voting fails, I'd say.

which is what FIG is supposed to be standing up for

No, you are confusing http://www.phptherightway.com/ with FIG. FIG is about Framework-Interoperability, which (in other words) means "let's stop stepping on each other work and let's work together", where the we in the scope of the sentence is "frameworks" or "libraries", and has nothing to do with end-users. The fact that end-users get shiny things such as psr-0 is a side-effect.

It should be Injector imho

Injector does not apply, mainly because then we'd design an interface for a factory, and tbh, callable is already enough for that. Also, factories vary too much between frameworks to actually standardize them right now.

If you want to explore the injector concept more, then feel free to write down a new proposal that deals with DI configuration/setup and all the details that can be commonly adopted by all frameworks.
A discussion was already started in #27.
I personally disagree with it, but it takes a lot of exploration to actually define how an injector works, and you also have to remember that defining an interface means also that you cannot dictate any implementation details, just the consumer API.
You'll see for yourself that it drills down to a locator again, regardless how perfect your injector prototype actually becomes. If that's not the case, then I'd like to see such an interface, as I've also been looking into it for a while.

[J7mbo]

@Ocramius Ah yes, I was confusing FIG and phptherightway ;D Thanks for your response

[XedinUnknown]

Hi! Sorry to bother 12 participants, but this seemed like the most appropriate place to ask this.

Nowhere in the inline or otherwise docs have I managed to find whether methods implementing ContainerInterface#get() return singletons, i.e. always the same instance, only initializing it on the first call. Or does this standard intentionally omit this? If so, I think this information should be included in the docs.

[mnapoli]

@XedinUnknown Could you please open a new issue? It's a different discussion, and people involved in this one might not be interested in this new one (especially since it involves a lot of people)