On 5/13/21 4:59 PM, Alan Snyder wrote: > > >> On May 13, 2021, at 2:03 AM, Andrew Haley <a...@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
