ScopedValue: Capturing current bindings

[Robert Engels]

Yes. Use lisp if you want that. Java doesn’t need it. 

A great developer can write great code given tools they understand. If your hammer turns in a screwdriver that might be great for people needing a screwdriver. But they should have started with one. 

The complexity of a system cannot be judged by designer - it can only be judged by those that maintain it. 

> On Jun 1, 2023, at 11:36 PM, Rosetta Roberts <rosettafroberts at gmail.com> wrote:
> 
> 
> 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/6805941b/attachment.htm>