You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now the package just writes to stdout, which is terrible. It is also super verbose.
The caller should decide where logging goes, and how much of it.
Some help from #go-nuts:
20:28Z <Habbie> what's the right way to add 'debug logging' to a library? the library doesn't know what logging lib, if any, the app is using
20:29Z <X> dependency injection
20:29Z <Habbie> X, do you have a few more words on that for me?
20:29Z <X> golang dependency injection interface
20:30Z <Habbie> ah yes
20:30Z <X> I'd also avoid logging to a constant stderr/stdout if this is a package; let the user decide where the logs end up (have them supply a log function or at least an io.Writer to log to)
20:31Z <Habbie> it would be a package, yes; and indeed i don't want to log to stdout/stderr unless the consumer wanted me to
20:31Z <Habbie> but in other projects i saw log libs being mixed and it was a mess
20:31Z <X> be careful with races (just printing is not thread-safe, the funcs/meths in the log package are)
20:31Z <Habbie> 'have them supply a log function' is roughly what you meant by dependency injection?
20:31Z <X> I'd stay away from depending on a specific logger package, indeed.
20:31Z <X> accept a simple interface.
20:32Z <Habbie> that's how i understood it
20:32Z <Habbie> perfect, thanks
20:32Z <Habbie> still getting my head around what's common and useful to do in Go
20:36Z <X> Habbie: I tend to do it something like this. [see next paste]
20:36Z <X> perhaps there's a better way.
20:41Z <Habbie> X, thanks, will digest that in a bit :)
20:43Z <y> Habbie: information from debug.Stack() works well for me as I am able to see the line numbers in my applications log files & relate to source code on my end
20:43Z <Habbie> y, ah thanks, that's what i always do in Lua indeed
20:44Z <y> Compared to the thread-unsafe nonsense that C++ stack traces were when I tried this method, I found golangs to work very reliably
package main
import "log"
func main() {
withoutLogging := NewMyPackageType()
withoutLogging.DoStuff()
withLogging := NewMyPackageType(
WithDebugLogf(log.Printf),
)
withLogging.DoStuff()
}
type MyPackageType struct {
debugLogf func(format string, v ...interface{})
}
func NewMyPackageType(opts ...func(*MyPackageType)) *MyPackageType {
t := &MyPackageType{
debugLogf: func(string, ...interface{}) {},
}
for _, o := range opts {
o(t)
}
return t
}
func (t *MyPackageType) DoStuff() {
t.debugLogf("look I'm %s logging", "debug")
}
func WithDebugLogf(f func(format string, v ...interface{})) func(*MyPackageType) {
return func(t *MyPackageType) {
t.debugLogf = f
}
}
The text was updated successfully, but these errors were encountered:
Right now the package just writes to stdout, which is terrible. It is also super verbose.
The caller should decide where logging goes, and how much of it.
Some help from #go-nuts:
The text was updated successfully, but these errors were encountered: