Scoped variables

[Ron Pressler]

We haven’t had much time to spend on this recently, and we certainly have no conclusions as of yet,
but this is sure to become an area of focus once the more basic areas of the API have stabilized.

We are, however, very much interested in hearing some thoughts about this. In particular, is the idea
of a binding with a dynamic scope that reverts to the old value when we exit the scope a better one
than the existing un-scoped lifetime of ThreadLocals, whose value persists until the next time it is set?

Ron


On July 11, 2019 at 6:38:37 PM, Jon Harper (jon.harper87 at gmail.com) wrote:

Hi list,  
I read with much interest the "scoped variable" discussion from  
December 2018: https://mail.openjdk.java.net/pipermail/loom-dev/2018-December/thread.html  

Towards the end of the conversation, the following was stated:  

> dean.long at oracle.com ; 12/7/18 1:15 PM  
> Now might be a good time to start a discussion on how we want scoped variables to be created and named.  
> Doug Lea dl at cs.oswego.edu ; Sun Dec 9 14:32:07 UTC 2018  
> Or backing up further, how about a discussion of use cases that should be covered?  

Has this been done and is there a link to a conclusion ?  

My favorite use case is implementing what various logging frameworks  
call Diagnostic Contexts in a way that is safe for everyone, whether  
they use threads manually or abstracted behind Executors (or using  
loom's fibers). I think the current agreement is that Diagnostic  
Contexts are too dangerous (currently implemented with threadlocals)  
because they can spill from one context to another when using  
Executors, resulting in false logs. Logs are a prime example where you  
don't want to explicitly pass a context object everywhere but still  
want your logs to display contextual informations (like a request id).  
This is especially true when you want to add a new log somewhere in  
the code where the context is not passed and you have to backtrack all  
the call chain and add the context object to all the intermediate  
method arguments.  

Cheers,  
Jon