Reuse of generic Clojure/ClojureScript code?

[Dave Sann]

Hi,

I have been using clojure for personal projects for a while now. I am starting to work with clojurescript. 

I have a number of utilities and libraries that I use in clojure. I can port much of these wholesale to clojurescript if I copy functions to cljs files.

Generally, my feeling is that I would like to be able to separate "generic clojure" from "jvm clojure" from "js clojure". Where "generic clojure" relies only on common capabilities of clojure or clojurescript. "jvm clojure" uses specific jvm/java libs and "js clojure" uses specifically js libs or capabilities.

As I understand it, even if I do this, I cannot use clojurescript-compatible clj files in a clojurescript build. (i.e compile the clj file as cljs).

Presumably, I could link or rename the files, but I think that in the long run this would be a maintenance challenge. Likewise for copying - if the code is meant to be the same.

Does anyone have opinions about how to maximise reuse of existing generic clojure code as cljs code in this manner? ( I know you can require-macros - but this does not work for : defn - for example - unless I am mistaken)

Do people feel that this sort of separation would be useful or of marginal benefit?

As a corollary (if separation and reuse were possible):

 - it would be quite useful to he able to define a library as being intended to be generic. The compiler would raise an error if a non-generic capability was employed somewhere in the library dependencies (i.e some inter-op or platform specific lib)

 - and to be able to require/use a "jvm" or "js" specific implementation of a library (implementing the same api/functions) depending on the compilation context...

It may be that some of this is possible with macros etc...my depth of knowledge is limited.

I am interested to hear opinions...

Cheers

Dave

[David Nolen]

As far as I know, coming up with a solution for this under consideration.

David

--
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

[Dave Sann]

ok

[Dave Sann]

If anyone is interested, this is the strategy that I am currently using. It's a bit messy with linking but it saves me maintaining multiple versions and has worked so far. I expect that the linking could be removed with some work upstream. This is a workaround for me until a more standard solution comes out.

I have started to separate code that I believe to be generic form code that I believe to be platform specific. It is not always possible to tell due to included dependencies, so there may be some trial and error.

If I am making a project - say 'utils' that I think can be used across clj and cljs, I use the following structure:

I put generic code in src.

I put jvm specific code in src/utlis/x (namespace utils.x and below)

I put cljs/js specific code in src_cljs/utils/x (namespace utils.x and below)

Generic code is developed under src and sym-linked into src_cljs - with a change in extension to .cljs

All platform dependent code is in or under the namespace utils.x (I use x because it's short and easy to see). This is not crosslinked (obviously).

I do not use 'cljs' or 'jvm' as the name space for platform specific code. Using the same prefix 'x' allows generic code to freely use platform specific code provided that it is explicitly implemented to the same API in both clj and cljs. This may not always be a reasonable thing to do, but where it is it seems effective.

Nothing special is required beyond this. I use cljs-watch to compile the clojurescript by pointing it at the src_cljs directory.

Cheers

Dave

[Laurent PETIT]

Hmm, I think the maven convention will start to make sense, somehow :

src/main/java/

->

src/main/java/
src/main/clojure/ ; clojure only code (jvm that is)
src/main/clojurescript/ ; clojurescript only code
src/main/clojure&script/ ; shared by clojure or clojurescript : no
bounty, but better name than "clojure&script" welcome

2011/10/6 Dave Sann <dave...@gmail.com>:

[pmbauer]

Do you know if that solution will extend to sharing clojure core libraries where that makes sense (a lot of copy-n-pasted code in [core|set|string|walk|zip].cljs)?

[Dave Sann]

fair enough.

Is there any support for this at the moment?

My only comment would be that it is quite handy to know that you have imported code that might be platform specific.

It also seems reasonable that pure clojure code might be used by the .net version.

Cheers

Dave

[Dave Sann]

I don't see why not, in principle. 

However, from my perspective when compiling at the moment, these are already taken care of. 

So I have not looked into this side of things.

I think that it would need some thought to get the best solution.

Cheers

D

[Alen Ribic]

Thanks Dave for sharing you current strategy for reusing generic
Clojure/ClojureScript code.
Have a look at the following dev thread where some ideas have been
shared and feel free to comment:

http://groups.google.com/group/clojure-dev/browse_thread/thread/831b74363da10187/3403e5ccbc488bc3

I haven't had much chance to take this further, however I will get
back to it this coming week.

-Alen

[Dave Sann]

If/when clojurescript gets in-ns and load the previously outlined solution could be improved.

I could use load to include platform specific ports of intended core library capability into the generic files. This would mean that you would only need to require the generic file, regardless of platform.

requiring or using a .x library would be used only where functionality was not planned or intended to be made portable.

This would be very handy

Is it planned for these functions to be developed?

Cheers

Dave