Hello, I was looking at the code generated by reify a bit, and I have noticed that in production build it preserves the N conditionals for each namespace segment.

I wonder if this can be avoided.

I have tried to implement an experimental reify variant that uses different exists? impl, that results in a more simple checking on dev build:

if((typeof app.main.data.viewer.t_app$main$data$viewer57870 !== 'undefined')){
} else {
(app.main.data.viewer.t_app$main$data$viewer57870 = (function (){

The question here is, how troublesome can this be? In development build at the end and at the end everything loads in order, and if it does not load in order, other problems will also appear (so checking segments is it possible that it is redundant?) In the production build, access to the generated class variable is done directly, so checking the existence of variables that represent the namespace segments also looks redundant. I'm wrong?

I have tried it in a large codebase that uses reify extensively and everything is working as expected (prod and dev builds), but i want to ask here if I'm missing something evident...

@niwinz https://clojure.atlassian.net/browse/CLJS-3055

somewhat related https://ask.clojure.org/index.php/8879/cljs-should-macros-support-lifting-vars-to-the-ns-level since with this reify wouldn't need that check at all

also related https://clojure.atlassian.net/browse/CLJS-3207 😉

thanks @thheller

the reason exists? checks all the nested stuff is because previously it would blow up if namespaces didn't actually exist. so checking app.main.data would fail and break the check if there was no app.main

not a problem reify will ever have but exists? in general might

yeah, this is something what i thought