chaining with options #4

Closed
wants to merge 2 commits into
from

Conversation

Projects
None yet
2 participants
@thinkt4nk

returned exports from options method, so as to support the following use case. I think it's very convenient.

var logly = require('logly').options({ date: true, color: true });

logger( input, 'error' );
};
-var stderr = function( input ) {
+var stderr = function() {
+ var input = Array.prototype.join.call(arguments,' ');

This comment has been minimized.

Show comment Hide comment
@tristanls

tristanls Oct 10, 2012

Owner

I like where you're going with this, however this breaks the use case of passing in a function as 'input'. Notice that:

var test = function () {
  var input = Array.prototype.join.call( arguments, ' ' );
  console.log( typeof( input ) );
};
test( function () {} ); // -> "string" ?!

I think it can still work but might require more type checking? (ironically :D)

@tristanls

tristanls Oct 10, 2012

Owner

I like where you're going with this, however this breaks the use case of passing in a function as 'input'. Notice that:

var test = function () {
  var input = Array.prototype.join.call( arguments, ' ' );
  console.log( typeof( input ) );
};
test( function () {} ); // -> "string" ?!

I think it can still work but might require more type checking? (ironically :D)

This comment has been minimized.

Show comment Hide comment
@thinkt4nk

thinkt4nk Oct 10, 2012

I'm actually not sure what the point of the support for a callback is. What is the use case here? It seems to me that one could just call the callback outright, instead of passing to logly to execute.

@thinkt4nk

thinkt4nk Oct 10, 2012

I'm actually not sure what the point of the support for a callback is. What is the use case here? It seems to me that one could just call the callback outright, instead of passing to logly to execute.

This comment has been minimized.

Show comment Hide comment
@tristanls

tristanls Oct 12, 2012

Owner

I don't fully understand what you mean by "call the callback outright". The use case for the callback is to prevent unnecessarily executing functions that could end up being quite complex, if we are not in debug mode or such. I was hoping the README example would illustrate it well:

functions as input

logly also accepts functions as input; this is primarily to conditionally produce a debug output of complex something if in debug mode, for example:

var options = { debug: true, output: "some.file" }
// dump options in debug mode
logly.debug( function() {
  for ( var i = 0; i < options.length; i++ ) {
    logly.debug( '[OPTION] ' + option + ": " + options[ option ] );
  }
});
// stdout: myapp[debug]: [OPTION] debug: true
// stdout: myapp[debug]: [OPTION] output: some.file

So, setting this "optimization" of not executing a function unnecessarily aside, I'm still trying to grasp how calling it outright would achieve the same goal. Are you suggesting that in the example above I should just do the for loop, and the logly.debug will end up a no-op if not in DEBUG mode? I guess that would go back to this being an "optimization".

I'm using "optimization" in quotes here because any sort of magical JavaScript parser could technically remove logly.debug statements if not compiling in DEBUG mode. That seems to be overly complex perhaps, and that's why leaving the functions as input should be retained?(thinking out loud here)

@tristanls

tristanls Oct 12, 2012

Owner

I don't fully understand what you mean by "call the callback outright". The use case for the callback is to prevent unnecessarily executing functions that could end up being quite complex, if we are not in debug mode or such. I was hoping the README example would illustrate it well:

functions as input

logly also accepts functions as input; this is primarily to conditionally produce a debug output of complex something if in debug mode, for example:

var options = { debug: true, output: "some.file" }
// dump options in debug mode
logly.debug( function() {
  for ( var i = 0; i < options.length; i++ ) {
    logly.debug( '[OPTION] ' + option + ": " + options[ option ] );
  }
});
// stdout: myapp[debug]: [OPTION] debug: true
// stdout: myapp[debug]: [OPTION] output: some.file

So, setting this "optimization" of not executing a function unnecessarily aside, I'm still trying to grasp how calling it outright would achieve the same goal. Are you suggesting that in the example above I should just do the for loop, and the logly.debug will end up a no-op if not in DEBUG mode? I guess that would go back to this being an "optimization".

I'm using "optimization" in quotes here because any sort of magical JavaScript parser could technically remove logly.debug statements if not compiling in DEBUG mode. That seems to be overly complex perhaps, and that's why leaving the functions as input should be retained?(thinking out loud here)

@@ -152,6 +159,7 @@ exports.name = function( applicationName ) {
exports.options = function( opts ) {
options.colourText = (('color' in opts) ? (opts.color === true) : (('colour' in opts) ? (opts.colour === true) : options.colourText));
options.datePrefix = (('date' in opts) ? opts.date : options.datePrefix);
+ return exports;

This comment has been minimized.

Show comment Hide comment
@tristanls

tristanls Oct 10, 2012

Owner

great addition!

@tristanls

tristanls Oct 10, 2012

Owner

great addition!

@tristanls

This comment has been minimized.

Show comment Hide comment
@tristanls

tristanls Nov 28, 2012

Owner

Closing due to lack of interest.

Owner

tristanls commented Nov 28, 2012

Closing due to lack of interest.

@tristanls tristanls closed this Nov 28, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment