search

plumatic / dommy

A tiny ClojureScript DOM manipulation and event library
758 stars 74 forks source link

Request for CLJS version doc #82

Open kylecordes opened 9 years ago

kylecordes commented 9 years ago

Hello. Naturally things are continually shifting when using a stack consisting almost entirely of pre-release software... but it would be helpful to have a few words here (or better yet, in the README) about what version(s) of CLJS Dommy is believed to work with.

jeluard commented 9 years ago

I noticed a bunch of warnings with latest ClojureScript 2342 version: WARNING: Use of undeclared Var dommy.template/->node-like at line ...

kylecordes commented 9 years ago

I saw that also, and noticed there was nothing here about versions - hence this item.

atroche commented 9 years ago

Same issue here

p-b-west commented 9 years ago

The problem, I think, is that there are circular dependencies between the files. From clojurescript 2341, this seems to have been picked up, even though, according to David Nolan, it has never been legal in either Clojure or ClojureScript.

template requires attrs. attrs use(s)-macros macros :only node

The "node" macro from macros generates code which calls ->node-like ->node-like is defn'd in template.

I think that is the source of the circularity.

I tried to resolve this, but every time I touched anything dommy broke. It's a bit of a tangle in there. As well as that, I don't understand the namespace issues in involved in the path from clojure macros to clojurescript expansions.

loganlinn commented 9 years ago

For an update, we have work-in-progress to address these namespace dependency issues (#85). When we release that (sometime this week), we will also document any CLJS version details. Thanks

p-b-west commented 9 years ago

Puzzling over the code, I notice that there is a mix of defmacro, def and defn in macros.clj. Mocaros can only be defined in clojure files; fair enough. However, the non-quoted parts of the macros are being compiled in the clojure compilation step. Therefore, the clojure compiler needs defns for, e.g., as-str, which is used extensively, unquoted, in the macro definitions. Consequently, there is a defn for as-str in macros.clj (as clojure.) However, the clojure components are only there to support the macro definitions, which will be called from within the cljs files. Sure enough, as-str has an identical definition in utils.cljs.

Isn't this redundant? The fact that clojurescript defmacro must be compiled by the clojure compiler, when there will be no clojure in sight when this code is executed, surely means that there should be no clojure evaluation of the content of a macro definition. For instance, in the cases where as-str is used in a defmacro, as-str should be quoted. In that case, there is not need for the clojure compiler to attempt to resolve a call to as-str; that is left to the clojurescript code that expands the macro.

Ot so ti seems to me. Does this make sense to anyone else? Or have I misunderstood something basic here?

loganlinn commented 9 years ago

@numinasthmatic Thanks for taking time to read through the source. Indeed, understanding macros can be confusing, especially ClojureScript ones. Not going to go into too much detail here as this is an off-topic subject, but the reason why you would want a function to exist in both Clojure and ClojureScript is to apply optimizations at compile time, when possible, otherwise fallback to a runtime (CLJS) version. This is a common practice.