Have you considered returning a lazy seq of events? On Tuesday, 2 June 2015, Christopher Small <metasoar...@gmail.com> wrote:
> > 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> 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> >>> 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 >>>> 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 >>>> 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. >>>> 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 >>> 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 >>> 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. >>> 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 > <javascript:_e(%7B%7D,'cvml','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 > <javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@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 > <javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@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.
