Do you know of some namespace, fn name, or related thing I could search for in ClojureScript implementation code, for whatever way it is that Olical cljs-test-runner starts up a node process? It doesn't seem to be the same way as --repl-env node
does.
I am guessing it is compiling all of the ClojureScript test code of a project that it finds all at once to JavaScript, and only then starts the node process
I guess asking the dev of cljs-test-runner might be appropriate.
In a flash of what might be called 'low inspiration', I commented out the definition of cljs.core/enable-console-print!
in my local copy of ClojureScript source, and found that Olical cljs-test-runner uses a library doo
that calls enable-console-print!
. OK, tracked that down. Related to CLJS-3153, in case you are wondering why I am trying to find this out.
Clojure has hasheq for Clojure-specific hash codes of values, including collections, which are in general different than what the Java hashCode method returns. Is there some JavaScript 'standard' for what objects return as a hash for the object, that ClojureScript implements, similar to Java .hashCode?
No because value semantics are just not a thing in the JS outside primitive values. Js has four different equality semantics. Only one of them is extensible (hackily via valueOf or toString) and only when comparing an object to a primitive, not object to object. There’s also nothing in js to consume custom hashing/equality anyway. Js object keys must be strings (thus string equality/hashing) or symbols (thus identity equality) Map
and Set
use identity. Outside JS core, the goog lib (closure) has an object id mechanism(used by cljs), but this is only for making object identity available as a value. It doesn’t have any data structures with value semantics. Immutable.js is the only thing I can think of that tried this: it looks for hashCode
, but this is not part of the js ecosystem consciousness. Ref: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Equality_comparisons_and_sameness
Bottom line, in js, library authors simply do not write types anticipating that they be used with value semantics. In Java at least there is some concern that an object can be a sensible key in HashMap
; in JS there is not even that.