Lots of great thoughts here; thanks so much for the feedback! It seems the general opinion so far leans towards keeping things simple. I definitely resonate with this statement: "having to write some glue code feels less frustrating than when libs make assumptions that I don't like."
Unfortunately, the abstractness of my question is allowing things to drift a little further than I intended. So to ground things a bit, in my particular use case promises wouldn't work because I need to allow for a stream of events. Promises only let you capture a single event. Additionally, I feel it worth responding to some of Timothy's comments about the difficulty of getting a core.async centric API "right". While I agree that in general (and particular with more complicated APIs) getting things right can be tricky, the situation I'm dealing with (I think) can be dealt with quite simply. Imagine a stream of events coming in from The Real World (TM), and that we'd like to process somehow. The solution I've been chewing on is a function that let's us specify a single channel on which events should be placed. The nice thing about this is that it assumes almost nothing about how you'll use core.async, only that you'll be using it. You can decide whether you want a buffer or not, whether it should drop or slide or block/park, whether it should be tapped, etc. The potentially nice thing about core.async for this use case over callbacks (as far as the implementation is concerned) is that should we decide to stop listening to events, we can just close! the channel. This can then serve as a signal to the underlying code/process actually reading in events that it can stop. With callbacks, it will probably be necessary to have something that manages these processes and listens for kill signals, potentially complicating things quite a bit. (It's possible there is an elegant solution here, and I haven't thought about it too much yet, but this is my current intuition...) I should also mention that Manifold did come to mind for this project, and it's something I'll probably look at and consider again. Thanks for bringing it up. Please continue to share your thoughts given all this :-) With gratitude Chris On Monday, June 1, 2015 at 10:18:46 PM UTC-7, Leonardo Borges wrote: > > For people interested in using the 'futures' approach, this might be of > interest: https://github.com/leonardoborges/imminent > > > It's a library that implements composable futures for Clojure on top of > JVM's ForkJoin framework. It allows you to attach callbacks as well as > apply combinators such as map etc... > > > On 2 Jun 2015 3:04 pm, "Timothy Baldridge" <tbald...@gmail.com > <javascript:>> wrote: > >> The problem with futures is that you can't attach callbacks to them, you >> can only block a thread waiting on them. So futures interface quite poorly >> with async libraries, hence the reason core.async was created in the first >> place. >> >> Core.async is a dependency, but it's hardly one that changes fast. The >> last breaking change was about a year and a half ago (Jan 2014). Besides >> that, all changes are additional "opt-in" features. That's a lot less >> change than most libraries in the Clojure ecosystem. >> >> Timothy >> >> On Mon, Jun 1, 2015 at 10:42 PM, Stanislav Yurin <jus...@gmail.com >> <javascript:>> wrote: >> >>> As for the core.async, I think it is too personal and has too much raw >>> power, to be all that restricted in some logical bottleneck upon results >>> return from the third-party lib. >>> Not counting the fact it is a (a) dependency that (b) changes fast. >>> >>> On Monday, June 1, 2015 at 10:18:19 PM UTC+3, 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 clo...@googlegroups.com >>> <javascript:> >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+u...@googlegroups.com <javascript:> >>> 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+u...@googlegroups.com <javascript:>. >>> 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 clo...@googlegroups.com >> <javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> 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+u...@googlegroups.com <javascript:>. >> 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.
