Using (var) emits path name of source file into js code

[AndyR]

I just messed with multimethods and :hierarchy which expects a var (#' or var). Doing so emitted my full path name of the cljs file into the JS file (meta data). Is this on purpose?

Could this be potentially a security issue?

Could we add a compiler option to sanitize this?

Cheers,
Andy

[David Nolen]

There is no intention to elide this information. static vars are primarily intended for development and testing - don't use them in production is the answer for the time being.

David

--
Note that posts from new members are moderated - please be patient with your first post.
---
You received this message because you are subscribed to the Google Groups "ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojurescrip...@googlegroups.com.
To post to this group, send email to clojur...@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

[AndyR]

Makes sense.

I just went through the source and it looks like all it does is deref it. So I just replaced it with an atom and passed that in to :hierarchy and it works just fine (even swap!ing it after the defmulti).

Can/Should I rely on this? If not, could this be added as "feature" to the doc string? As far as I can tell :hierarchy is one of the very very few non-dev oriented usages of a #'var. So it would be nice if we could use without getting into the var mess.

(I'm planning on using :hierarchy to handle core.async messages where I might want to handle multiple messages with the same handler.)

[AndyR]

FYI: It already says so in the docs string:
"Multimethods expect the value of the hierarchy option to be supplied as
a reference type e.g. a var (i.e. via the Var-quote dispatch macro #'
or the var special form)."

My mind was too set on Vars because that's what the few examples use. So it does work fine (and documented so) with refs, atoms and vars and probably all that is IDeref.

Cheers