[WIP] use Labels command more than once

[kitagry]

relate #16
This is experimental PR.
zerodriver.Event wrap all methods of zerolog.Event. This is not elegant way, but go way. (> <)

This is not good in following points.

• This is fragile when zerolog.Event was changed
• This is difficult to test. Should we test all of methods?

If you don't like it, feel free to close it

[hirosassa]

Thanks for the PR!

This is fragile when zerolog.Event was changed

Yeah, but this library is already heavily depend on zerolog, so I think it is OK.

This is difficult to test. Should we test all of methods?

Since your implementation simply wrapped zerolog's methods, I think it is unnecessary to test all of it. You can skip it.

[kitagry]

I'm sorry for the late response.
Thank you!

I'll fix some errors.

[kitagry]

I'm sorry. This PR can't resolve #16, because zerolog.Event has side effects.

// prepare common label
commonLogger := logger.Info().Labels(zerodriver.Label("label", "common"))

commonLogger.Labels("phase", "1").Msg("hoge")
// ok

commonLogger.Labels("phase", "2").Msg("fuga")
// want: {..., "logging.googleapis.com/labels": {"label": "common", "phase": "2"}}
// got:  {..., "logging.googleapis.com/labels": {"label": "common", "phase": "1"}, "logging.googleapis.com/labels": {"label": "common", "phase": "2"}}

So, if we solve this, we should copy zerolog.Event. But this lose the strength of zerolog(non-allocation).

[kitagry]

Hmm. This is very difficult problem. All zerolog.Event methods have side effects, so we can't reuse it.
Maybe we should copy structs, but there are private fields. So this approach can't solve the issue.

I'll close this PR once. And, if I come up with the solution, I will open new PR.
Thank you.