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