Fork me on GitHub

I had an issue where I had two functions in a file, replace-_ and replace_-. This worked in dev, but when I aot the project, any invocation of either is replaced by the last one in the file. I suppose this is because munge gives the same result for both those names. Is this a known issue?


"known" as in "there's a JIRA ticket because it's a bug"? or as in "yes, munge produces the same JVM-level name for both because that's just how it works"? 🙂


I don't remember anyone specifically mentioning it as a problem -- but I don't know whether the behavior of munge is documented anywhere in a way that would make the possibility of collisions obvious...


@madstap I assume your functions are related to converting names between kebab-case and snake_case?


Yeah, exactly


I figure I should at least get a warning or something....


Yeah, I'd say it's worth opening a JIRA ticket to add a compilation warning about name-munging producing collisions...


@madstap what is the fully-qualified class name of the fn in the aot'ed jar?


@the2bears The clojure names of the fns are foo.common.core/replace-_ (and replace_-). The class in the jar is /foo/common/core$replace__.class


Yeah, interesting... like you stated, the munging is very ambiguous in this case 🙂


I could be wrong, but it isn't clear to me whether there is a straightforward way for the compiler to detect that name-munging produces collisions. I say that because there is no warning, and likely never will be, if you defn the same function name multiple times (same even before the name is munged). Detecting that was one of the motivating use cases for me hacking on Eastwood for a while.


Clojure has no warning for that because it is such a common use case in REPL workflows to redefine functions.


But perhaps in the specific case of 'during aot compilation' it might be straightforward to detect when writing a .class file that already exists.


which would also remind people to clean out their stale class files


@madstap What version of Clojure are you using? This behavior might be better with Clojure 1.9 than in Clojure 1.8.


I'm on 1.9


Never mind on my last comment -- I think I confused myself with some test expressions I was evaluating.


No promises on whether Eastwood ever will have such a check, but I've created a Github issue for it in case someone decides to run with the idea and implement it:

👍 4