Goog.debug

[stumitchell]

Right in our projects we have moved to explicitly changing the value of js/goog.DEBUG to indicate a production build.

Would you be open to changing the behaviour of clairvoyant to use this switch instead?

Sorry for the churn but we do now think this is a better more explicit way of indicating a production build.

I have tested this as well and the closure compiler does remove the dead code produced by this macro with :advanced optimizations.

Stu

[noprompt]

I'm not 100% sure on this one. Both approaches result in the same outcome right?

[mike-thompson-day8]

The asserts approach is indirect. It is a bit sneaky. It means that, to get dead code elimination, you have to ALSO remove all asserts. Long ago, I learned to leave asserts in production code.

Whereas the goog.DEBUG approach is direct. It seems a much saner approach.

The only downside to the goog.DEBUG approach is that it does require optimisations :advanced compilation to achieve dead code elimination. :simple won't get you there.

[mike-thompson-day8]

This cljs feature has just landed:
clojure/clojurescript@5ef5f10

Now we have compile time constants which can be oveerriden for all :optimizations targets, perhaps we drop use of the generic goog.DEBUG compile time constant and, instead, create a clairvoyant-specific constant which controls the generation of trace.

[danielcompton]

When running unit tests, Clairvoyant is a bit noisy, having a Closure constant would probably be the most flexible option for this. Are you open to a patch for this behaviour?