Thought: extension-aware handling

[Peter Taoussanis]

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! :-)

[Chas Emerick]

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.

[Peter Taoussanis]

Sure, no rush at all. Cheers :-)