I'd say stick with callbacks simply because they're harder to mess up. There's many different ways to interface with core.async. You can return a channel, you can require a channel as an argument. You can spin up go blocks that park, you can have pipelines, you can create a go block per call to an api, or one that lives for the lifetime of the app. Some APIs can have cancelable operations, some don't. Knowing how to build an API that fits everyones needs is really hard.
Sadly, I don't trust many people (including myself) to implement a core.async API correctly for the needs of every application. But callbacks are pretty hard to mess up. Just document where the callbacks are run (on a single thread, in a thread pool, etc.) and I can easily adapt your library to fit my application. Timothy On Mon, Jun 1, 2015 at 7:05 PM, Alejandro Ciniglio <skiae...@gmail.com> wrote: > That’s a fair point. Although, I think manifold does have going for it > that it’s designed to interoperate with the other abstractions we’re > discussing, so it shouldn’t be as binding as building your API around > core.async would be. > > On June 1, 2015 at 8:20:18 PM, Andrey Antukh (n...@niwi.nz) wrote: > > Hi! > > Personally I think that manifold has the same problem that core.async. So > if you are exposing your api using manifold you are forcing to someone to > use manifold. It is not bad, but is the same problem as with core.async. > > And the same problem with callbacks. If you are using callbacks you are > force to people to use callbacks or adapt it to whatever other abstraction. > > So, independently of the chosen abstraction, you are always forcing the > user to use the chosen abstraction or adapt their code to another > abstraction. > > About the original question, I think it depends that you really wants. In > some projects I expose api using inter operable with jvm abstractions like > (reactive-streams) or promises (completable future in jdk8), in other I > just use core.async. > > There is no single solution I think! > > My two cents! > > Andrey > > On Mon, Jun 1, 2015 at 9:57 PM, Alejandro Ciniglio <skiae...@gmail.com> > wrote: > >> Zach Tellman talks about exactly this in his conj talk from last year >> https://www.youtube.com/watch?v=3oQTSP4FngY >> >> He built a library around this that essentially gives the library user a >> choice of either option: https://github.com/ztellman/manifold >> >> >> On Monday, June 1, 2015 at 3:18:19 PM UTC-4, Christopher Small wrote: >>> >>> Greetings >>> >>> I imagine most of us here would rather use core.async channels over >>> callbacks in their application code, particularly with more complicated >>> applications. But is it okay/preferable for Clojure libraries to force >>> their users to use core.async channels as part of an API (an event channel, >>> for example)? >>> >>> As much as I love core.async, I can't help but wonder whether sticking >>> with callbacks for an API isn't a simpler/better design strategy. It's easy >>> enough to drop messages on a channel in a callback, and this let's users >>> opt-in. But if one expects core.async channels are what most would prefer >>> anyway, is it okay to foist them upon everyone? >>> >>> As a follow up, does your opinion on the matter change if >>> implementations of an API become simpler using core.async channels? >>> >>> >>> Looking forward to your thoughts :-) >>> >>> Chris Small >>> >>> >>> >>> PS I'm asking because I'm working on a physical computing API ( >>> https://github.com/clj-bots/pin-ctrl) and debating between using >>> channels vs callbacks for the edge detection functionality (if you're not >>> familiar, edge detection let's you asynchronously handle changes in pin >>> state, such as button pushes). If you're interested in this question as it >>> applies specifically to this application, feel free to join the discussion >>> on our gitter channel: https://gitter.im/clj-bots/chat >>> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Andrey Antukh - Андрей Антух - <n...@niwi.nz> > http://www.niwi.nz > https://github.com/niwinz > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/nuy2CAA89sI/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
