JEP draft: Scope Locals

[Andrew Haley]

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