> Thanks for the suggestion, but I'd rather not do it this way, because the API > will suffer. When I call getAccessCode from an external module, I'm expecting > to get the access code in return, not a Future that should be awaited on. So, > one way or the other, I need a regular function returning a regular string.
That's not how you should design such APIs. Doing it this way means that the caller has no choice but to block. If you return a `Future` then the caller can at least decide whether to run the code asynchronously or not. > I'm doing some work with Google Drive API. To obtain the access token, I have > to receive a request, make another request, and extract data from it. So I > need a proc that would start a server, receive a request, do a request, > receive another request, shut down the server, and return the response. I'm > using the standard asynchttpserver and httpclient modules. Are you sure you need both a server and a client for this? It seems over complicated to me but I don't know how the Google Drive API works. > This method works just fine, but I don't like it for its explicitness. Also, > using a closure to pass data into and retrieve it from the callback doesn't > look safe, but I can't see any other way to do it. If you really want to keep your semantics then your procedure seems fine. But instead of using the closure to pass data into it you should just define more parameters in your `callback` proc and pass the data as arguments.
