Warning when using private vars
Description
Environment
Attachments
Activity

Mike Fikes July 4, 2018 at 5:01 PM

Mike Fikes July 4, 2018 at 3:01 PM
CLJS-1702-10.patch rebaselines
David Nolen June 15, 2018 at 10:46 PM
Thanks will review.

Mike Fikes June 15, 2018 at 10:36 PM
CLJS-1702-9.patch is the same as CLJS-1702-8.patch, except that it eliminates an explicit deref
call that had been added, reverting to using @
.

Mike Fikes June 15, 2018 at 10:26 PM
CLJS-1702-8.patch dispenses with the metadata.
There are two odd cases that arose in this last patch:
Since the private
checked-get
(and friends) specifically trigger analysis warnings based on their symbol (see https://github.com/clojure/clojurescript/blob/6950aff480174a25a77c2308aa87a099a774a6e8/src/main/clojure/cljs/analyzer.cljc#L3558), attempting to use var indirection to avoid private var warnings on them defeats the strategy of triggering the logic on those symbols. The latest patch fixes that by piling on a little more special handling for those symbols, suppressing the private var warning for them.If you spec some private functions and then, from another namespace, enable spec instrumentation, the macros involved end up calling
set!
on the relevant symbols, and, since they are private, the private var warning will trigger. I couldn't think of a clean way to cope with this, so the revised patch takes the heavy-handed approach of simply turning off private var access warnings when analyzingset!
forms. (Perhaps this is OK: when you are usingset!
and the target happens to be a var, you are already doing something a bit advanced in your code and presumably you know what you are doing?)
Currently no warning or error of any kind is given. Throwing an error and forcing users to go through vars is somewhat less attractive since vars dump information like file, line, etc. A warning would be a simple way to flag users that they are treading into dangerous territory. Downstream tooling error handling can make it a hard error if they like.