stucture::optionFromField that cares about capital letters

[celian-garcia]

Hello guy,
Thanks for this work, this is really great.

I have an idea that I'd want to implement in gonfig but I want to have your advice first.

The optionFromField function takes the field name and build the id from it using this code :

	id := f.Tag.Get(fieldTagID)
	if len(id) == 0 {
		id = strings.ToLower(f.Name)
	}
	opt.id = id

Problem is when I have for example the struct field LogLevel, I'd want my config file corresponding field to be log_level.

I can obviously define my struct field like that

type ServerConfiguration struct {
	Port int 		`env:"SERVER_PORT" default:"8080"`
	LogLevel string `id:"log_level" env:"SERVER_LOG_LEVEL" default:"<root>=ERROR"`
}

But I'd prefer to count on a default behaviour.
There I have an issue, what to choose as default behavior :

• snake case : log_level
• camel case : logLevel

Maybe we could use as default what you already implemented, but have the possibility to override it in the gonfig.Conf what do you think about it ?

See you !

[celian-garcia]

I could even make a code which supports both syntax without configure anything :)

[stevenroose]

Hmm. Keep in mind that we have three different aspects. F.e. camel casing should never be used in environment variables or in CLI flags. In CLI flags, a dash is the default splitting character and in environment variables, the underscore. In config files, there are multiple options. Perhaps we can do something like a variable `SplitCamelCase`. Then dashes can be used for CLI args and underscores for environment variables. Then the only question is to pick a default for config files. I think underscores are fine. If someone really wants to have alternative config variable names, we can have an enum-var with different options. How does that sound?

…

On Sun, Dec 2, 2018, 10:50 Célian GARCIA ***@***.***> wrote: I could even make a code which supports both syntax without configure anything :) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#24 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA0F3Bz5VwjyqDWn0WNuc1ijEtZBwAYYks5u06JngaJpZM4Y9Uyg> .

[celian-garcia]

I agree about the dashes for CLI arguments and underscores for environment variables.

About the config parameters, I am wondering if I couldn' t do something which parse equally camel case, kebab case, and snake case into same variable.

So that we could have a config file like that (json example):

{
  "my-super-var": "hello",
  "an_other_syntax": "wonderful",
  "evenOtherSyntax": "world",
  "youWantToMix_No-problem": "man"
}

that would match a struct like this:

type Config struct {
  MySuperVar string
  AnOtherSyntax string
  EvenOtherSyntax string
  YouWantToMixNoProblem string
}

[celian-garcia]

Yeah I know I'm a bit crazy ^^