ScopedValue: Capturing current bindings

[Pedro Lamarão]

Em qui., 1 de jun. de 2023 às 18:27, Attila Kelemen <
attila.kelemen85 at gmail.com> escreveu:


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

But this is a cross thread relationship, right? The scoping in this case is
transversal to lexical scoping or thread scoping. A bean that is bound to
some sub-context of the application context, is bound during a time that is
defined by the application life cycle, not by some call chain active in
some thread. Why would one implement all this inside ScopedValue?

-- 
Pedro Lamarão
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230601/eed20cbb/attachment.htm>