On 8/27/13 10:03 AM, Dave Ray wrote:
Hi.
I'm writing to see if there's anyone out there using RxJava [1] from
Clojure and to get their opinion on it's current, built-in support for
non-Java languages.
Just to recap, the current implementation knows about clojure.lang.IFn
allowing functions to be passed directly to RxJava methods:
(-> my-observable
(.map (fn [v] (Long/parseLong v)))
(.reduce +))
RxJava will automatically convert these functions to the underlying
rx.util.functions.FuncX interface and re-dispatch to the appropriate
method.
So, the question is: as a user of RxJava, how valuable is this
feature? Do you just end up wrapping things anyway, so you could
easily perform the same transformation in your wrapper? Would helper
fns/macros be a sufficient alternative:
(-> my-observable
(.map (rx/fn [v] (Long/parseLong v)))
(.reduce (rx/fn* +)))
There will be some changes in this area in the near future and we'd
like to get a feel for if/how people are using RxJava from Clojure.
Thanks!
Dave
[1] https://github.com/Netflix/RxJava
Hi Dave,
We've been using RxJava from Clojure in production for a bit now but in
a limited fashion. While I saw many places where I would want to wrap
RxJava I ended up not and instead just used the built-in methods since
they played nicely with clojure fns. How valuable is it? It has been
nice for our limited use but I think for a larger project we would end
up wrapping it anyways. (I would probably wrap the methods like .map,
etc, so that they just take fns). So if it makes things easier for
RxJava to drop the support I say drop it.
I've been thinking that the clojure community could benefit from a
clj-rx project that that would define protocols for all the Rx
primitives and a consistent API which could be implemented in a number
of ways but would all adhere to the Rx contract. RxJava and core.async
being the two most obvious implementations but others could also wrap Rx
js libs for use in ClojureScript if they needed to. I know your
question is specifically about RxJava but if you are going down the
route of wrapping it in a nice idiomatic clojure API it may be worth
taking a step back and seeing if taking the protocol approach makes
sense. I'd be interesting in collaborating on this if you decide to go
down this route.
On a related Rx/core.async note... At work we are now using core.async
for many of the workflows where I would have otherwise reached for Rx
(and vanilla java.util.cc). I've been finding that some tasks are much
easier to think about using CSP and allow you to model certain processes
in a clearer way. Other times I find myself reaching for the nice
abstraction Rx brings and I usually end up implementing some of the
functions on top of core.async (similar to what Brandon Bloom has done
in his experimental lib). This is why thinking having a unified clj-rx
API warrants further exploration. I'd love to hear other peoples
thoughts on this as well.
-Ben
--
--
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/groups/opt_out.
