ScopedValue: Capturing current bindings

[Attila Kelemen]

>
>
> 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.
>
>
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).

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230601/5235c0fa/attachment-0001.htm>