-
Notifications
You must be signed in to change notification settings - Fork 9
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
Simplify API proposal #18
Comments
Regarding the For the design, the chain operation allows us to add all kinds of fields, configs, and logger in one operation. I know the chain operation is not idiomatic but I think it's more convenient than doing the I agree with the problem your first example present on accessing the logger directly. Because of #17 it might be good to hide the logger methods. |
It might be worth splitting this out into a few issues so we can discuss and track separately. My take on the split would be:
And leave the remainder (Simpler API for fields vs logger, and the actual proposal) in this ticket |
YAGNI. Can you give a specific example of a problem it solves? I can give an example of a problem it introduces: you've now got a way to get into an infinite loop without really realising it. fields.WithFunc("foo", func(ctx context.Context) interface{} {
return util.getValueOfFoo(ctx)
}).Onto(ctx)
// somewhere else, some utility package etc
func getValueOfFoo(ctx context.Context) string {
log.From(ctx).Info("getting value of foo") // infinite recursion here
return "bar"
} |
* update otel to v0.19 * update go to 1.15
Is there a reason why we need access to the logger directly? Logging is inherently global (stdout is all you need) so I can't think of a strong reason a developer might need direct access to the logger. If there is a reason, we can still expose it such that it hints to the engineer that they really should know what they are doing.
Some other thoughts I have about the existing API:
From
andOnto
are a bit obscure, could lead to bugs where a logger is used in the wrong contextfields.WithFunc
. It opens up a class of bugs and accidental misuse that seems far worse than the problem it solves.With that said, here's my thinking on a simple pragmatic API.
Example usage
I'm willing to be persuaded here. I would love your thoughts.
The text was updated successfully, but these errors were encountered: