I apologize if this is naïve and/or incomplete; I'm very new to Clojure. Would a better solution be to use something closer to protocols and multimethods, where functions could be "polymorphic" by platform rather than polymorphic by arguments?
This would make it open for users to add support for platforms the library author didn't support. At a quick glance, it looks like a feature expression wouldn't allow for this. Andrew Oberstar On Sat, Nov 15, 2014, 6:56 AM Daniel Kersten <dkers...@gmail.com> wrote: > I didn't ask for feature expressions in the survey, but I've been wishing > for a better way for writing cross-target code, especially libraries. > > I've never quite managed to bring myself to develop with cljx - I love it > as a consumer of libraries, but I haven't quite managed to make it wo > wellrk in my workflow for my own code, so haven't been using it. > I've found it a bit too slow and clunky and don't quite know how it fits > with other tools I use: eg, browser repl, figwheel, devcards. > I also find it less than desirable to run yet another java process > alongside my client nrepl, cljsbuild auto (or figwheel) and server clj > application. Its already a heavier weight setup than I'd like. > > I imagine most of these concerns can be addressed in cljx itself, of > course, but as it stands it's not ideal and improvements are needed > -somewhere-. If it's part of the reader, though, then I don't need a > separate stage. Plus any code invoking the reader would be target aware. > > On Sat, 15 Nov 2014 12:08 Julien Eluard <julien.elu...@gmail.com> wrote: > >> Hi Colin, >> >> CLJX definitively does the job but at the price of being very brittle and >> having to juggle with paths and classpaths. Also this is a leaky hack as >> you have to make all tooling aware of it (editor, nrepl, ..). It usually >> sort of work up to the point it doesn't. CLJX does the magic by generating >> files and I must be aware of it while I would expect this to disappear with >> Feature Expressions. >> I would very much like to see something like that standardized and >> transparent. >> >> Some specific answers: >> 3. No. This goes much beyond. On the browser you have access to much more >> than one would expect being part of a standard librairies. >> See [1] for an example. >> Also it's not clear how macro could be handled this way. >> >> 4. Node support (and related scenario) is a real problem. It's not clear >> to me how to handle it and if this should be addressed by Feature >> Expressions. See [2] for a concrete example. >> >> >> [1] https://github.com/davidsantiago/hickory >> [2] https://github.com/davidsantiago/hickory/issues/17 >> >> Julien >> >> 2014-11-15 4:09 GMT-03:00 Max Kreminski <maxkremin...@gmail.com>: >> >> On Friday, November 14, 2014 7:22:39 PM UTC-8, Colin Fleming wrote: >>> > Hi all, >>> > >>> > There's a discussion going on right now on clojure-dev ( >>> https://groups.google.com/d/topic/clojure-dev/6pnIeXFRwnI/discussion) >>> about the Feature Expressions functionality currently slated for Clojure >>> 1.7. This was one of the most requested features in the recent state of >>> clj/cljs survey, particularly by cljs users. However there seems to be a >>> lot of confusion about exactly what the needs are here. I think everyone >>> would be very interested in feedback, either here or on the clojure-dev >>> thread if you have access, on why this is so important to cljs users. >>> Specifically: >>> > Is there something specific in the current proposal that is especially >>> attractive to you, or is Feature Expressions more a proxy for "it should be >>> easier to write cross-platform code"?Is there a strong argument for having >>> this in the language, instead of in a tool like CLJX? Is this a fundamental >>> failing of CLJX, or is the tooling perhaps just more awkward to use than it >>> could be? >>> > Could these needs be totally or mostly met by better cross platform >>> libraries, like string and date handling?Would more features be useful than >>> simply "this is CLJS code", i.e. would this be helpful for Node support? Is >>> there no other way to get that support, i.e. through better libraries or >>> macros? >>> > I don't know the answers to any of these questions or have strong >>> opinions about them since I don't use CLJS or CLJX, but I do write tooling >>> that has to support them so I'd really like to understand this better. >>> > >>> > If any of you are interested in this and will be at the conj, there'll >>> be an unsession about Feature Expressions there - please come and tell us >>> what you think! >>> > Cheers, >>> > Colin >>> >>> I'm primarily a ClojureScript dev but I sometimes work with Clojure on >>> the JVM as well. Here's my perspective. >>> >>> 1. I have no strong feelings about feature expressions in particular; >>> I'm just excited to see the core team endorsing anything that will make >>> cross-platform development simpler out of the box. >>> >>> 2. I have no major problems with CLJX (I suppose it's a bit of a hack, >>> but it suffices for my purposes) except that of adoption. If I want to make >>> any of the Clojure core repos CLJS-compatible, I can't use CLJX to write >>> shared platform-agnostic code – the core team doesn't allow it. If a >>> particular JVM Clojure library's maintainer doesn't like CLJX for whatever >>> reason, I can't use that library in my CLJS project without forking it and >>> maintaining the fork. At the moment, Clojure and CLJS code are incompatible >>> by default, which feels like the opposite of how things "should be". >>> >>> 3. Better cross-platform libraries might get us halfway there but they >>> won't completely obviate the need for CLJX, feature expressions, or >>> something similar. When trying to write cross-platform exception handling >>> code, for instance, I still regularly find myself needing to replace >>> instances of "Exception" with "js/Error"; as long as these sorts of >>> situations are still coming up I'll always want to have something like CLJX >>> or feature expressions in my toolbox. >>> >>> 4. I can't really speak to this point too much, as I've never really run >>> into any problems trying to work with e.g. Node vs browser JS. In the long >>> term it might make sense to divide the "Clojure platform" into a set of >>> specific features (e.g. macros, reified namespaces, clojure.string, etc) >>> and allow users to test whether each of these features is "present" on any >>> given implementation, but whether there exists an actual use-case for this >>> is beyond me and it seems totally out of scope for the current discussion >>> anyway. >>> >>> To get on my soapbox for a bit, I think the gap between Clojure and CLJS >>> is gradually widening because the language as currently implemented makes >>> it difficult to write and maintain cross-platform code. CLJX's feature set >>> is all I really need, but right now every member of the community has to >>> specifically "opt in" to writing cross-platform code by manually setting up >>> CLJX for every project. Couple that with the fact that I specifically can't >>> use CLJX when I'm contributing to the core libraries, and we wind up with a >>> lot of duplicated effort on both sides of the Clojure/CLJS fence. >>> >>> The sooner we get feature expressions or something equivalent baked into >>> core, the better. Only once the core team has blessed a particular solution >>> will we see the current situation replaced by the "cross-platform by >>> default" scenario I'd prefer. >>> >>> -- >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "ClojureScript" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojurescript+unsubscr...@googlegroups.com. >>> To post to this group, send email to clojurescript@googlegroups.com. >>> Visit this group at http://groups.google.com/group/clojurescript. >>> >> -- >> Note that posts from new members are moderated - please be patient with >> your first post. >> --- >> You received this message because you are subscribed to the Google Groups >> "ClojureScript" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojurescript+unsubscr...@googlegroups.com. >> To post to this group, send email to clojurescript@googlegroups.com. >> Visit this group at http://groups.google.com/group/clojurescript. >> > -- > Note that posts from new members are moderated - please be patient with > your first post. > --- > You received this message because you are subscribed to the Google Groups > "ClojureScript" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojurescript+unsubscr...@googlegroups.com. > To post to this group, send email to clojurescript@googlegroups.com. > Visit this group at http://groups.google.com/group/clojurescript. > -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
