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