ScopedValue: Capturing current bindings

[Rosetta Roberts]

This sort of scoping isn't a new paradigm. It is equivalent to dynamic
scoping which was present in the original lisp introduced in 1960; it is
older than C.

Though, I think using scoping like this for resource management or
dependency injection is still rather new.

On Thu, Jun 1, 2023, 23:28 Robert Engels <rengels at ix.netcom.com> wrote:

> I think you would really like Rust.
>
> Java needs to stop trying to address every new paradigm that becomes hot.
>
> People wrote really great software in Java 1. This continual added
> complexity is only going to make it obsolete.
>
> If it doesn’t read like Java - it’s not Java - and it doesn’t belong.
>
> Create the fiefdoms elsewhere.
>
> On Jun 1, 2023, at 5:15 PM, Attila Kelemen <attila.kelemen85 at gmail.com>
> wrote:
>
> 
>
>>
>> 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?
>>
>>
> The way I imagine, is that in the future you could design an application
> around scopes (in the abstract, SV is just a visible thing in the scope).
> That is, all your application is a single tree of scopes, and all the
> application code is within a scope. In this world, scopes would be a
> natural candidate to be used as DI contexts, because scopes have a well
> defined life-cycle, and that would make arguing about the lifetime and
> ownership (and who can have access to them) of resources easy. To me at
> least it is always a big pain point that it is hard to prove that a
> resource that has a given lifetime is not used outside its lifetime, and
> also that I can limit its life to a minimum. And since scopes would/could
> be the owner of resources, it makes sense to inject them via the scopes as
> well (since you know that whatever you injected this way is alive at that
> point).
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230601/f4c26e6a/attachment.htm>