liwp/again

CLJC for ClojureScript support

Closed this issue · 2 comments

conan commented

I'd like to use again in ClojureScript, but unfortunately it uses bigint, Exception and Thread, which aren't available in Javascript. It seems like it would be fairly easy to convert this to a .cljc project, because javascript numbers are (2^53)-1 bytes which in ms is over 285 millenia, and (catch Exception e) can be replaced with (catch :default e). Sleeping is more difficult however.

I'm happy to write a PR to do this, but is it worth it? Adding a js equivalent of Thread.sleep() will require either the use of js/setTimeout directly, or the addition of core.async; I suspect the latter will be cleaner, but would involve the addition of a dependency to a nicely independent project. In addition, reader conditionals are pretty ugly for dependencies. Either way things will get nastier because of the lack of multithreading in Javascript.

liwp commented

Hi @conan. Yes please, I'm open for a PR for cljs support.

My initial plan was to support both clj and cljs, but like you point out, I realised that Thread.sleep() didn't exist and decided to punt on cljs for the time being.

I don't think you can implement the required blocking behaviour without core.async (unless you have async/await available somehow), but feel free to prove me wrong 😄 Another reason I wasn't keen to tackle cljs support was the added dependency, as you said. For that reason, I'd really like to see only the cljs build depend on core.async. I'm not sure what's the best way to do that - maybe not declare core.async as a dependecy and documenting that the user has to declare it in their project - dunno.

As for whether it's worth it or not... I don't have a need for it at the moment, but it sounds like you do and, like I said, my original plan was to support both. Maybe the best approach for you would be to 'rewrite' the library in your own project (I mean the project that you want to use the library in) and see what the result looks like (the core of again is really simple, the bulk of the code is the strategy builders which you might not need). If it still seems like a good idea, start looking into a PR with all the cljc machinery etc. The point being that you wouldn't have to worry about clj support until it's proven that i) the library is useful in a cljs project, and ii) the cljc implementation is possible / sensible.

Let me know what you think.

liwp commented

I'm closing this for now since there haven't been any other requests around it. I'd love to add supports, and I think it should be relatively simple apart from the Thread.sleep() issue.