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.

Reply via email to