Hey David, Thank you for your comments. I will try to write what I am looking for.
> > Basically this is the text : > > > > Two successive calls to get with the same identifier SHOULD return the > same > > value. However, depending on the implementor design and/or user > > configuration, different values might be returned, so user SHOULD NOT > rely > > on getting the same value on 2 successive calls. > > > > I don't want to drag everyone again to the same discussion. But I wonder > if > > there is any implementors having any concern about the same. > > Just like @mwop, I've never had an issue with this behaviour. > Yes, I looked into the zend event manager https://docs.zendframework.com/zend-eventmanager/quick-start/ to understand what @mwop was mentioning. It do contain a shared event manager instance , so if someone need to pass that shared instance probably I don't know what they really do. > Actually, I'd be interested in knowing what is your concern with this? Do > you have an actual use case in mind that absolutely requires the container > to always return the same value for all entries? > I may be wrong, but these are the few things I have in mind. You can say it is application level configuration, but at the end of the day every PSR is used by application developers. 1. Getting an instance of SignalManager : Aura makes use of single shared signal manager, but you can make it as not shared also. https://github.com/auraphp/Aura.Signal#signals-by-class 2. Database connections are always shared one. You never expect different connections each time. You can argue to create wrappers or do in the configuration level. But for a specification it should be very clear what it returns as Pedro Cordeiro mentioned in this thread. Always returns new instance or You will always get the same object. > We can of course work on standardizing the notion of "factories" like > described here (https://github.com/container-interop/container-interop/ > issues/44) but this is IMHO a whole different PSR as factories may/should > not be containers. > I don't think it need to be a different PSR itself for every containers have the functionality for the same. Either in configuration or having a different method. So why not suggest a method itself ? I understand that the object creation inside Factory can be using "new" keyword than using the container itself ie why you suggested a different PSR. You can create a different PSR for sure. So in that case as in discussion https://github.com/container-interop/container-interop/issues/69#issuecomment-251316682 it will be something like class SomeContainer implements ContainerInterface, FactoryInterface {} Now your container's get can return new or shared instance depending on configuration and make / create can create new instances. Didn't we removed the configuration level of container to return shared / new instances if we say "get" always return same instance and "make / create" always create new instance ? As this discussion started 2 days before and none of the existing FIG 3.0 members have the problem may be this is only concern for me. We can wrap this up if there is no further issues raised. Thank you -- 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/CAESZFtLxee52fmj0kgadTy%3DmTuoe3%3DF-nDqcfLhqYPTg9vnuxA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
