On Tue, Jun 2, 2015 at 3:17 AM, Christopher Small <metasoar...@gmail.com> wrote:
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. > I like and use core.async, but this sounds like something that I might want to handle with a compositional event system like RxJava. A simple callback-based API would suffice for that. 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...) > Good point. CES systems that I’ve used have a first-class notions of “stream complete” and “stream errored”, which is even more expressive than core.async‘s “send nil“. If your API offered three separate callbacks (one for each of those conditions and one for values, with the invariant that if either the “stream complete” or “stream errored” callback fires for a stream, no further callbacks will be invoked), it would be pretty easy for a user to map them to their CES equivalents, and if someone prefers to work in core.async, they can send whatever value they wish on the channel, followed by nil. e -- 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.
