
Programming with Configuration Contexts - tadasv
http://vilkeliskis.com/blog/2015/11/28/programming_with_config_contexts.html
======
iofj
If we're programmers and "devops" why does anyone bother with this sort of
thing ? If ops team can, and does, recompile everything regularly then why not
just have them as constants in the code, or in some cases just directly in the
code ?

There is no excuse for added complexity and this is a bad one.

~~~
dozzie
> If ops team can, and does, recompile everything regularly then why not just
> have them as constants in the code, or in some cases just directly in the
> code ?

Because the ops team does not recompile everything regularly, and sometimes
needs to run a service with different config in an ad-hoc manner.

Also, aiming the code at being configured when being run yields better
separation between code configuring the thing and code that runs it. If you
can't see what profit comes from keeping configuration separate from code, I'm
affraid you won't be able to gather configuration in one place easy to change.

------
kazinator
Just call it a "configuration", not a "configuration context"!

"Context" means nothing, because you can't flip a bit without it being in some
kind of context. What is an object? It's a piece of context which holds named
properties.

(Particularly, when you're parsing a "context free" grammar, there is
shitloads of context just to ironically spite you.)

------
icholy
I'd be more inclined to name it ServerOptions instead of ServerContext.

