Thought: extension-aware handling
ptaoussanis opened this issue · comments
Hi Chas! Just thinking out loud here...
The two major workflow patterns seem to be:
- Separate
/src/clj
,src/cljs
,src/cljx
dirs. - A single
/src
dir with mixed.clj
,.cljs
,.cljx
files as necessary.
In both of these cases there's a tricky choice that needs to be made when a namespace is predominantly but not entirely single-platform. The choice is:
- Split the cross-platform code into another ns.
- Make the entire ns a
.cljx
file with appropriate annotations everywhere.
It occurs to me that an alternative may be worth thinking about:
- The Cljx transformer picks up all relevant file extensions:
.clj
,.cljs
,.cljx
. - Its behaviour depends on the file extension being processed.
Within .cljx
files, we have the usual #+clj
and #+cljs
annotations.
Within .clj
files, everything is assumed to be #+clj
unless otherwise annotated.
Within .cljs
files, everything is assumed to be #+cljs
unless otherwise annotated.
This'd allow a convenient third choice to the problem above: use a file extension (.clj
/.cljs
) appropriate for the majority of the ns code and add a minimal number of annotations for the few alternate-platform bits.
(With this capability I'd suggest that the second workflow pattern would make a sensible default recommendation btw, but that's tangential).
There is a snag:
There would be an ambiguity in .clj
/.cljs
files whether #+cljs
/#+clj
means "this code only for that platform", or "also" for that platform. Some ideas off the top of my head:
- Add a
#+cljx
annotation to mean "both platforms" [1]. - Add
#+clj-also
#+cljs-also
or equivalent annotations (my preference). - Allow
#+clj
and#+cljs
to both coexist on the same form somehow (seems distasteful + possibly tricky?).
[1] At first I thought the #+cljx
annotation may be limiting (what if we have additional platforms later?) - but in fact this is the default behaviour anyway with .cljx
files currently so may be reasonable.
Curious to get your feedback on this. Anyway, enjoy the rest of your weekend - cheers! :-)
This is interesting, I'll have to think about it some.
One thing that is convenient about having the separate filetype is that the nREPL middleware can readily identify (and therefore not transform at all) non-cljx files that provide a namespace being required. I don't think losing this capability would be so bad, but it's something to consider.
Sure, no rush at all. Cheers :-)