Closed tyranron closed 7 years ago
This is not strictly necessary.... I actually kind of regret adding struct fields to the struct directly... you can use some other struct to serialize the values in whatever format you like and then pass them to lumberjack. I personally love TOML, but I don't think I want to encourage a proliferation of struct tags added on for everyone's favorite configuration language.
@natefinch I understand your concern.
you can use some other struct to serialize the values in whatever format you like and then pass them to lumberjack
Yeah. This is the way to go. But when it comes to using a lot of configuration for different libraries, or using the same library which requires such configuration in many projects, the necessity to write such wrapper type every single time just pisses me off 😤
In my opinion, such small "sugar" features make library developer friendly a lot.
but I don't think I want to encourage a proliferation of struct tags added on for everyone's favorite configuration language
Totally agree. The only reason I proposed TOML is because it has become quite popular and widely used recently. Any configuration that I've met last years was either YAML, JSON, or TOML.
If it was .ini
format this PR would never exist 🙂
So, no offense, and I'm totally OK with declining this PR.
It's just a proposal to be a bit more developer friendly in most cases.
Also note that as long as you match the capitalization of the struct fields, you can still use this struct directly:
Filename = "foo.log"
MaxSize = 100 #megabytes
MaxAge = 30 #days
MaxBackups = 3
LocalTime = true
In addition to YAML and JSON this simple PR adds support for TOML fields.