On Tue, Jun 2, 2015 at 7:18 AM, Leonardo Borges <leonardoborges...@gmail.com > 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... > Great library, thanks for sharing. I have done something similar, only focused on promise abstraction and with focus on using existing jvm implementation instead of creating a new one: https://funcool.github.io/futura/latest/#_promises > > On 2 Jun 2015 3:04 pm, "Timothy Baldridge" <tbaldri...@gmail.com> 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 <jusk...@gmail.com> >> 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 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. >> > -- > 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.
