JEP draft: Scope Locals

[Alan Snyder]

> 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.


>> 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.


>> Is this feature just a workaround for poorly designed libraries, or are there other examples?
> 
> It's not really about poor design as much as separation of concerns.
> Intermediate libraries have no way to know what might need to be passed
> to callees, and in many cases it's better isolation if they don't get to
> find out. The latter is especially true of passing security permissions.
> 
> Also, there is evolution of libraries: with scope locals you don't need
> to change library interfaces to add useful capabilities like logging.
> 
> -- 
> 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
>