On Sep 1, 3:31 pm, Chouser <
chou...@gmail.com> wrote:
Firstly, I'd like to thank you for the suggestion and provide some
comment.
Besides the obvious benefits of the :languages option approach, here
are some noteworthy disadvantages:
* Developer cannot, at a glance, identify what compiler the file is
targeted for as it has the common file extension.
* When giving the compiler a source directory instead of a source
file, the compiler will have to filter, potentially a large set of,
source files that support the target language.
* And finally, Clojure core `ns` macro would most probably have to be
changed in order to interpret the addition of the :langauges option
I have spent some time contemplating other possible solutions and I
believe that I have one that might be worth perusing.
Action:
* Keep extensions as is (Clojure: clj, ClojureScript: cljs).
* At compile time, create temporary .cljs files for each dependency,
in a temp directory, for whom a .cljs source file is not found but
a .clj source file exists. (This is a compile time operation, let the
compiler delegate this sort of work as it already does when
renaming .cljs files to .js)
Benefits with this approach are as follows:
* Least impact on the existing ClojureScript codebase
* No impact on Clojure codebase
* Developer can identify, at a glance, what compiler the file is
targeted for by the extension.
* We already generate `target directory` (out/) that contains files
that are potentially temporary at least in case of advanced
optimization. So we don't really deter form this pattern.
Disadvantages:
* No real way of communicating the target languages supported by
source file. (Perhaps metadata entry would be sufficient: (ns
^{:doc ... :author ... :languages #{:clj :cljs}})
* Still faced with the problem that a .clj source file maybe picked as
a dependency when it was not meant to be one. (Maybe the metadata
entry suggestion above for `:languages` above could server as a *hint*
to the compiler?)
-Alen
>
> --Chouser