JEP draft: Scope Locals

[Alan Snyder]

The essence of the example seems to be that the callback is supporting multiple client contexts and when called needs to act relative to the specific client context.

The callback does not get a parameter identifying the client context because the library that calls it does not know anything about these client contexts.

Effectively, the callback uses the calling thread as a way to identify the client context.

That is not new. The ability to shadow/snapshot appears to be new, but it is still based on the thread as the ultimate context identifier.

Did I get it right?

If so, perhaps it would be less confusing if “Scope Locals” instead were called “Scoped Thread Locals”.





> On May 14, 2021, at 1:28 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 5/13/21 4:59 PM, Alan Snyder wrote:
>> 
>> 
>>> On May 13, 2021, at 2:03 AM, Andrew Haley <aph at redhat.com> wrote:
>>> 
>>> On 5/12/21 8:12 PM, Alan Snyder wrote:
>>>> From the motivation section:
>>>> 
>>>>> So you want to invoke a method |X| in a library that later calls back into your code. In your callback you need some context, perhaps a transaction ID or some |File| instances. However, |X| provides no way to pass a reference through their code into your callback. What are you to do?
>>>> 
>>>> When I read this, my first thought was… pass a callback that is bound to the context.
>>>> 
>>>> I suppose the example you have in mind has a fixed callback.
>>> 
>>> Fixed? It's a callback, of some form.
>> 
>> What I meant was that the callback has a larger scope than the method call. Otherwise, you could bind the context to the callback object.
> 
> I don't know quite what you mean by "larger scope," but clearly, if you
> can explicitly pass a callback created by a lambda, that's a more explicit
> solution.
> 
>>>> Is this a common practice? Doesn’t it point to a deficiency in the library API?
>>> 
>>> Not necessarily. For example, say you want to give access to a particular
>>> resource (a log stream, say) to trusted callees. Nobody AFAIK passes a log
>>> stream as an explicit argument through business logic because that's just
>>> too much clutter.
>> 
>> That sounds interesting, but I’m not following how scope locals would be used to solve this problem.
> 
> In the outer scope you bind a logger scope local, and all transitive callees
> can use that.
> 
> -- 
> 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
>