Fork me on GitHub

I was wondering, tools.namespace also unloads, but what if it didn't? Wouldn't that solve most of the caveats it has, at the expense of you could miss the fact one function calls something that no longer exists.


@didibus you'd need some kind of manual override if you changed a defmulti though, for example


True, I could get in the habit of having a (def my-multi nil) above them


But I'm also wondering here, maybe tools.namespace could be smarter and unmap defmultis but not the rest?


I also wouldn't be too bothered if when I changed a defmulti I still needed to manually deal with it


Are there other cases like this? Apart from defmulti?

Reily Siegel21:12:55

Is it possible to force Clojure to resolve import statements at compile time? Currently import statements produce bytecode that looks like

class_ = ((Namespace)RT.CURRENT_NS.deref()).importClass(RT.classForNameNonLoading((String)""));
I need to be able to run the resulting AOT'd clojure code through a java remapper (obfuscator), which does not seem to work when the imports are resolved in this way. Upon further inspection, this only happens in clojure_ns$loading___xxxx___auto__xxx.class. In all other instances, the import statement is resolved correctly and is properly converted by the remapper.