Config should allow for default values. about config

[havocp]

see https://groups.google.com/group/play-framework/browse_thread/thread/9857d18dd7328bf2?fwc=1 for some background on this issue. You can always define a Config with your defaults in code, myDefaults=ConfigFactory.parseMap(), then conf.withFallback(myDefaults), if reference.conf doesn't work in a given situation. Defaults passed to the getter inherently mean cut-and-paste code as soon as you get a setting in two places, right? better to ensure the Config falls back to defaults.

[viktorklang]

defaults in code is a bad practice.

[rkuhn]

I’d like to also put my weight in on the “no defaults in code” side. You can always include a reference.conf or application.conf for this purpose.

[patriknw]

My vote is also on no defaults in code.
reference.conf is great for documentation.

[havocp]

to be clear, I don't have a plan to add defaults to getters. but I did want to be sure @sheki's use case is covered by a reference.conf and/or putting a withFallback in code. basically want to be sure the issue is not knowing about those approaches (vs those approaches not working in some way)

[sheki]

I think the choice of using reference.conf or defaults in code should lie with the user.

[rkuhn]

You can already do that using config.withFallback(ConfigFactory.parseString(mydefaults)) or using hasPath() (where the latter is really only for things where the information whether it was configured or not is actually valuable/of interest).

[viktorklang]

I disagree, by making it hard to do the wrong thing, you foster people to do the right thing. Fostering people to do the right thing improves the world, fostering them to do the wrong thing makes it worse.

[havocp]

Always interested in use-cases that aren't covered by the current API, but as best I can think of, withFallback and reference.conf cover all the cases. I don't want to add another way to do it that involves a couple dozen extra methods and most would consider bad practice. At least not without some very strong rationale that I'm not yet aware of.

[LeifW]

Any clarification as to why "defaults in code" is considered bad practice?

[viktorklang]

Because they get sprinkled all over the code base, you risk having to repeat the code in several places which means risk of different defaults for the same value, it also leads to defensive code because no-one can trust the config, it is also hard to change the defaults without recompiling the entire project.