ScopedValue: Capturing current bindings

Attila Kelemen attila.kelemen85 at gmail.com
Thu Jun 1 15:11:56 UTC 2023


>
> With respect, I don't think you should approach the problem this way. If you have a DI framework which uses scoped values to determine what is bound, I think you'd be *much* better off binding a small number of contexts which are defined by the DI framework than you would be by binding everything that is available (which could be hundreds? thousands? ten thousands? of bound objects in real-world situations). You can very easily implement whatever functionality you want by wrapping the ScopedValue API without compromising the design principles of that API, rather than trying to make the ScopedValue API do something it is not intended for.
>

I would not want to do many bindings (only exactly 1 under normal
circumstances), but for the sake of this example, I did not want to
complicate it with issues irrelevant to the problem. Anyway, I don't
see how "wrapping the ScopedValue API" would solve my issue, because
my issue is that I cannot make this framework capture the current
bindings of scoped values and use them in a nested scope. Anyway - for
Andrew's request - I will soonish write an example API that the JDK
could provide to solve my problem (alongside with some exact
specification of what methods would do there). I hope that will
clarify my intent.

> I for one do not *ever* want any external framework to be able to re-bind context objects that I define without going through APIs that I control, under any circumstances. Encapsulation is a feature not a bug.

To be honest I don't understand what you are referring to here. I
would not intend to directly expose the SV to the client of the DI
framework.


More information about the loom-dev mailing list