<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>I don't understand this problem. What is this code that incorrectly rebound the factory to some inappropriate value? Why does this code have this power? There is an intuition here about DI frameworks that I also don't understand: that factory clients don't want the new-like operation to react to the actually current context, but must react to some previously-current-at-that-time context. Is this really how standard DI works? I would expect that, if my application updates the current context somehow, and then calls into a new-like operation, this call must be affect by the changes I just applied.</div><div><br></div></div></blockquote><div><br></div><div>Standard DI frameworks do not need to concern themselves with this since they do not even know about SV. However, in some abstract sense they do work this way (at least some do). For example, you can organize Spring's `ApplicationContext` instances into a tree. In which case a bean in the parent `ApplicationContext` will not see the beans in a child `ApplicationContext`. However, note that an SV based DI framework would use the SV bindings as its "ApplicationContext" (`ScopedValue.Snapshot` essentially). So, for such a framework it is an essential feature (if you want parent child relationships, which you often need).</div><div><br></div><div>As for "this call must be affected by the changes I just applied": This depends on what exactly we are talking about. For non-singleton objects, it might be the case (though usually I don't think so, because normally in a DI framework an injected object should depend on other objects managed by the DI framework), but for lazy singletons, it is definitely not something you want, because the context where the singleton would be created would be ill-defined (i.e., first use, which would be horribly fragile).</div></div></div>