-1 for metadata +1 for file extensions or paths. I don't think metadata or in-file conditional compilation is the right tool for this.
My reasons are as follows 1. I don't think it is a good idea to mix multi-platform definitions in one file. it gets complicated and confusing very quickly. You cant see the wood for the trees. 2. What about adding a new platform - do you edit the existing files or add a new one. 3. Different platform specifics could be maintained by different teams with only the port code required. Most people will not care about every platform. 4. Separating them means that you can very easily see what is platform specific and port. You can also easily produce separate source distributions if you so wish. 5. If you add metadata - then the complier must read the file in order to decide whether it needs to look process the contents or not. This will increase build times substantially as you add platforms. I don't know about platform versions - that could get very complicated. If following the extension route, you would also require an extension for generic clojure code vs jvm platform code in addition to the others. I like the idea of separate, parallel source paths: e.g. src/clj/blah.clj ;; "pure" clojure src/jvm/blah.clj ;; for the jvm src/py/blah.clj ;; etc src/clr/blah.clj src/cljs/blah.clj maybe - but not sure src/jvm/1.7/blah.clj ;; for the jvm (1.7) My tuppence worth. Dave On Friday, 13 April 2012 02:56:59 UTC+10, tbc++ wrote: > > I've been thinking lately how to seamlessly merge clojure-py and > clojure-jvm code in the same packages. This is something I know has > been discussed in the past, but I'm just looking for > ideas/brainstorming on how we can solve this problem. > > Let's begin by explaining the problem. Let's assume that my project > needs a platform specific way to convert a int to a string: > > On clojure-jvm: > > (defn to-string [i] (.toString Integer i)) > > On clojure-py: > > (defn to-string [i] (py/str i)) > > On Clojurescript: > > (defn to-string [i] (.toString i)) > > > We could do this inline (inside a common .clj file): > > (for-platform "jvm" > (defn to-string [i] (.toString Integer i)) > "python" > (defn to-string [i] (py/str i)) > "js" > (defn to-string [i] (.toString i))) > > But this gets ugly real fast. > > My idea, would be to provide some sort of hook to the compiler, that > would be cross-platform. The compiler, when looking for a namespace, > would find all files in a given folder that match the required > namespace: > > /test/to_string.clj > /test/to_string.cljpy > /test/to_string.cljs > /test/to_string.cljclr > > These function hooks would then pick the best entry based on the > extension, defaulting to .clj if no better option exists. Since these > functions could be composable it would be possible to also dispatch on > platform versions: > > /test/to_string.cljpy26 ; Python 2.6 code > /test/to_string.clj7 ; JVM 7 code > > It seems to me that this would be a very clean way to allow clojure > programs to be cross-platform. The side-effect is that it would force > non-standard code out into separate namespaces where they can be > easily maintained. If someone wanted to port the project to a new > platform, he would need only to find existing platform overrides, and > create new entries. > > > Thoughts? > > Timothy Baldridge > > -- 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
