On Nov 12, 1:22 am, nchubrich <nicholas.chubr...@gmail.com> wrote: > I'm curious what the best idiomatic way of handling events is (e.g. > receiving a series of messages and dispatching functions on the basis > of the messages). One could use the 'experimental' add-watch(er) > functions. But it might also be nice to do something stream-oriented, > e.g. a doseq on a stream of events. But the trouble is this dies as > soon as the events stop arriving. Can event seqs be 'kept alive' > somehow (preferably without blocking)? > This seems like a pretty basic capability, so I figured it was > worth provoking discussion about. > > Nick.
I think the typical way to handle this currently is by using a typical handler function that is called whenever an event is fired. If the events will be long running then you can use agents or a thread pool (executor framework). If you need to dispatch events to other handlers then use multi-methods. It seems that what you are really asking for though, is a way to treat a stream of events as a sequence. This is what they recently introduced in .net land, with the RX framework: http://www.leading-edge-dev.de/?p=501 Given that clojure has a nice library of sequence manipulation and predicate functions, I think doing something similar could be useful. I don't have a clear sense for how it would work though. You could form a pipeline of sequence processing functions that get called whenever a new event is fired, maybe by using a promise that gets fulfilled when the event hits the pipeline? -Jeff -- 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
