Why so? With a callback, someone should be waiting somewhere too, until callback is fired. Why not expose this choice to user. E.g. I am often waiting for the future in the (thread ..) and returning the result to the channel, but again, I like this to be my choice, because there are so much ways of doing this.
On Tuesday, June 2, 2015 at 8:04:38 AM UTC+3, tbc++ 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 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.