Treora commented on issue #115: URL: https://github.com/apache/incubator-annotator/issues/115#issuecomment-882519923
You are completely correct that there is no need for the current functions to be async. The reason they are async is to make it easier to do async stuff in the future, without needing to change the API. For example, fuzzy text search may be computationally expensive, and could be offloaded to a worker thread. Note that e.g. a `TextPositionSelector` can never produce multiple results, so besides not needing to be async its matcher would not even have be a generator. However, the idea is to have a coherency in the function signatures, and making all matchers return async generators seemed the most flexible option, allowing for easy composition of matchers; that is, to have a single function able to handle various types of Selectors, dispatching them to the appropriate functions, as we do [in the demo](https://github.com/apache/incubator-annotator/blob/a352fff9b9abda66d4627d4644ea5a2e2218d7c4/web/index.js#L101-L113). We are aware that this choice of generality does impose constraints on the users of the functions, who need to await each result, and whose functions thus have to become async themselves; ‘async infection’ as you call it. We have been thinking about a practical way to provide a synchronous API in addition to an asynchronous API. See the discussion in #81; suggestions are welcome! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@annotator.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
