I just figured out a thing which had been kind of muddy to me up to now, despite wrangling with it for a couple-few years.
This has multiple benefits, of which the main one is probably that you don't need any special loading mechanism and can refer to a config item from anywhere by invoking the class.
Now... this can be done either:
- as a dynamic class with a singleton method that auto-creates the object as the invoking class – so to access config params, you go something like
- as a static class, where you just access the params directly like
The static method is easier on the brain, but it doesn't allow for having descendant classes that override defaults or define abstracts...
(Oh, that's another benefit of a class-based config: you can do abstract methods for things that need to be filled in by specific apps or deployments.)
...because then the code has to know what class to use, and even if you somehow gently guide the endcoder into correctly naming their final config class, this greatly restrains flexibility. Using separate config classes for separate areas of concern imposes that same additional documentation/constriction overhead for each class you want to have, for example.
Using a dynamic class, on the other hand, means that the endcoder can call their config classes whatever they want (or even have multiple alternates for different situations), as long as they make sure to instantiate the classes they want to actually use before any other code needs to access configs. The endcoder's config-object then becomes ::Me(), which is what all the other code refers to for the actual config methods.
Actually, I'm not sure it's significant as I thought, now that I spell this all out... and I'm out of writing time for the moment.