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.
