Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[v1, 4/8] Replace NewJSON constructor with NewLogger #115

Merged
merged 3 commits into from
Aug 1, 2016

Conversation

akshayjshah
Copy link
Contributor

@akshayjshah akshayjshah commented Aug 1, 2016

Make the logger type name more generic, since it's not actually JSON-specific, and make the logger constructor take an encoder implementation. Since we're injecting encoders, we can stop using the ugly StubTime hack (which we'll remove altogether in the next PR).

This is the fourth of eight PRs to finish up the large pre-v1.0.0 refactoring:

  • Meta constructor takes an encoder
  • Export Encoder type
  • Export the JSON encoder constructor
  • Add a NewLogger constructor and remove NewJSON
  • Remove StubTime
  • Export the Hook type
  • Remove Encoder.AddFields (since we already have Field.AddTo)
  • Improve GoDoc.

The remaining items in the v1 milestone shouldn't require large-scale changes.

Akshay Shah added 2 commits August 1, 2016 10:01
Since loggers and encoders are now completely separate, make the main
constructor `NewLogger` and have it take an encoder as its first
argument. This requires changing many call sites.
@prashantv
Copy link
Collaborator

Did you consider this alternate interface:

  • New that creates a logger with all the default options + encoder
  • a zap.Encoder which lets you pass a custom encoder as an option

This makes creating a new default logger a fair bit more verbose:

zap.NewLogger(zap.NewJSONEncoder(), [..])

vs

zap.New([...])

And in the case that someone wants to customize the encoder, it's not very complicated either:

zap.New(zap.Encoder(zap.NewJSONEncoder()), [...])

@akshayjshah
Copy link
Contributor Author

I considered that (and roughed out some code), but ended up rejecting it for two reasons:

  1. It introduces an order dependency between the Fields and Encoder option, since changing the encoder discards any accumulated context. This is solvable, but definitely introduces more complexity.
  2. Even if we solve the first problem, I suspect that all production users will want to customize the encoder options. Timestamp formats, level enums, and envelope keys are just too deployment-specific for one-size-fits-all defaults. If users want to customize these options, using a functional option just introduces more noise.

@@ -86,7 +86,12 @@ func BenchmarkZapDisabledLevelsWithoutFields(b *testing.B) {

func BenchmarkZapDisabledLevelsAccumulatedContext(b *testing.B) {
context := fakeFields()
logger := zap.NewJSON(zap.ErrorLevel, zap.Output(zap.Discard), zap.Fields(context...))
logger := zap.NewLogger(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Optional: might be worth adding a helper to create a new JSON logger with output discarded, that takes a list of additional options on top.

@prashantv
Copy link
Collaborator

Makes sense. lgtm

@akshayjshah
Copy link
Contributor Author

Will change NewLogger to New, wait for tests, and then land.

@akshayjshah akshayjshah merged commit 4891e1d into master Aug 1, 2016
@akshayjshah akshayjshah deleted the ajs-inject-encoder-into-loggers branch August 1, 2016 20:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants