ScopedValue: Capturing current bindings
Andrew Haley
aph-open at littlepinkcloud.com
Thu Jun 1 09:07:12 UTC 2023
On 5/31/23 20:38, Attila Kelemen 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).
I think I understand that point.
However, scoped values restrict what is possible, by design. A
(conditional) goto is more powerful than any other control structure,
but we don't support gotos in Java because they make it hard to reason
about programs. Instead we use much more limited control structures.
Like function arguments, scoped values pass from caller to callee. I'm
very open to talking about ways to make scoped values more useful. We
figured out how to use StructuredTaskScope to share scoped values
between threads in a way that doesn't compromise any
guarantees. However, any structure that allows a scoped value to live
after its binding scope has terminated is out of the question because
it breaks a fundamental invariant.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
More information about the loom-dev
mailing list