ScopedValue: Capturing current bindings

[David Lloyd]

On Wed, May 31, 2023 at 2:39 PM Attila Kelemen <attila.kelemen85 at gmail.com>
wrote:

> The gain would be that I can use the upper bindings without worrying
> that there are new bindings. For my DI framework example, the problem
> is that a DI framework might want to bind a factory (maybe because it
> is a lazy singleton, or not a singleton at all), which is then queried
> ina nested scope. However, if we do not capture the current
> ScopedValue bindings at the time the DI framework captures its own
> factories, then the factories might behave differently depending on
> the context they were called for, and this would be unacceptable for a
> DI framework (you want very predictable behaviour for your factories).
>

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 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.
-- 
- DML • he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230601/b1411cc7/attachment.htm>