there have been a number of previous discussions FYI. This was one I could find:
https://groups.google.com/d/topic/clojure/LQcBEph-3Bg/discussion On Tuesday, 8 January 2013 22:24:26 UTC+11, Irakli Gozalishvili wrote: > > Hi Folks, > > I wanted to comment on "Feature Expressions" feature page, but it looks > like special privileges are required, so I thought I'd post my questions / > feedback here. > > I've being working on client side JS for a while and I'm well aware of > hazards associated with platform specific code branching. Although > solution that in my experience worked best, was move to more granular a > codebase, isolating platform specific code from a common one. > > I think this would be a great direction for clojure / clojurescript ? As a > matter of fact it would be tremendous help for newcomers like myself to > have a baseline libraries abstracting platform differences that would not > assume specific backgrounds in Java or JS. > > Please don't take this a wrong way, but I do believe most problems are not > caused by inability to switch between platform > specific code, but rather by a lack of baseline that would allow writing a > common code. > Here are few examples: > > Otherwise perfectly portable clojure compatible clojurescript code won't > work because in clojurescript one needs to extend > default type while in clojure it's Object instead. I don't know actual > reason here but have a feeling that common thing could > be created that would work for both. > https://github.com/Gozala/eventual-cljs/blob/master/src/core.cljs#L26 > > Another interesting case is try special form which clearly does not fits > JS since catching > exceptions by a classname does not really make much sense there. > http://clojure.org/special_forms#try > > Also as far as I can tell in order to throw an exception one need to > either access > js/Error or one of Exception classes on Java. > > I do believe identifying & fixing such cases, so that non > platform specific code could be written without accessing > platform specific constructs would solve most of the issues without > introducing further complexity. In fact it would > make platform more accessible for others. > > Another thing I wanted to point out was racket's submodules which may be > another interesting option to consider: > http://blog.racket-lang.org/2012/06/submodules.html > > > P.S: My apologies, if some of my comments are incorrect it could be that > I'm still missing important parts of the puzzle. > > Regards > -- > Irakli Gozalishvili > Web: http://www.jeditoolkit.com/ > > -- 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
