configurable log function (javascript) about json-template HOT 8 OPEN

log isn't defined in json-template.js.  It's only defined in test-helpers.js.  
Are
you using an old version?

I refer to you to line 23 on the current trunk.

To quote it:

// This is predefined in tests, shouldn't be defined anywhere else.  TODO: Do
// something nicer.
var log = log || function() {};

Oh, perhaps you don't consider this a definition of 'log'. It's just 
frustrating if
you want to change this and make log messages from json-template somewhere 
else, as
you'd write:

var log = function() {};

which would result in logs being turned off for *everything*.

Any log configuration system that json-template adopts to change whether you 
want to
log or not will need to modify the behavior of log, if you refer to it under 
this
global name.

It doesn't "clobber" the log function -- it uses the one that's there if it 
*already*
exists.

I agree that customizing the log function would be useful... if you have a 
scheme
that works for you please send in a patch.

It does write to 'log', just will write the same value back.  I'm
fine to retract the word 'clobber'. :)

Whatever it does, this approach makes it impossible to do something
*else* with that line like shut down json-template's voluminous
logging (while being interested in other logging by other js code), as the 
global name 'log' is in use throughout the json-template code. Perhaps there's 
some other way to selectively shut down logging from particular javascript 
modules?

In our copy of json-template we now renamed the uses of log to log2 so
we can shut down logging in json-template specifically when we want
to. That's hardly ideal. I'll look into a approach that does work
where json-template uses _log instead, adding an api to manipulate the logging 
situation.

I recommend dropping the globally-visible logging hook in favor of a 
locally-scoped
one.  So, define a "log()" function on one of the json-template classes, and 
provide
examples of how the user can attach it to the global "log()" function or a
user-defined function.  By default, leave this local "log()" function defined 
as a
no-op for best performance.

Yes, I agree with that approach.  log() shouldn't be in the global namespace.