opaque Config defaults

[jehiah]

It's not obvious from go-doc documentation what the default config values are, or what time some are, and there is no way to introspect them at runtime. Both seem like they should exist.

[mreiferson]

Yea, I still can't say that this is the best we can do but I do appreciate the consistency. We lost type safety, but we didn't gain or lose anything when it comes to things being invalid only at runtime.

What we gained is one consistent way to set them (which is also capable or accepting serialized values from config files or over the wire).

The docs are a good suggestion.

[mreiferson]

updated in bitly/master@43ff0ca

[jehiah]

The type safety is one thing, but i'm having issues loosing static analysis being able to catch typos much much more. I'm really thinking about ways we can export variables from the config structure, and still leverage the Set() interface for loading from config files, and command line args but not loose the static analysis.

[mreiferson]

I'm all ears 😄

[jehiah]

How about leaving everything exported in the config object so you can initialize fields directly while continuing to leverage everything Set() gives us for loading in via command line flags, generic extensible reader-args, or from config file. We would then use the config object in a way that it's only useful to set values on the config object before passing it into a consumer/producer. The Consumer/Producer objects would make a deep copy of the config and store it in an unexpected variable, and any fields we expect to be mutated would have their own API to change them (directly by copying default values from config into an exported field or through a wrapper function to address where state has to be coordinated).