Thanks for this library - it's great work.
It'd be nice (as a user) if I could mostly use regular core.async takes, and get back results which my application can understand without further processing.
My concern is that interleaving async/<! and client/<! in a project is a cost to the user (understanding the distinction, explaining it), without a clear benefit in most cases. Exposing the intermediate and final results could be done by namespace segregation (e.g. client/get! -> string, client.raw/get! -> BulkStr, or however), or avoided by deciding that some functions will always be strings.
On the null / closed channel distinction - which of the functions in the API return multiple values on a channel, with the possibility of nulls?
Thanks for this library - it's great work.
It'd be nice (as a user) if I could mostly use regular
core.asynctakes, and get back results which my application can understand without further processing.My concern is that interleaving
async/<!andclient/<!in a project is a cost to the user (understanding the distinction, explaining it), without a clear benefit in most cases. Exposing the intermediate and final results could be done by namespace segregation (e.g.client/get!-> string,client.raw/get!->BulkStr, or however), or avoided by deciding that some functions will always be strings.On the null / closed channel distinction - which of the functions in the API return multiple values on a channel, with the possibility of nulls?