Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
The goal of FCs (as listed in #2668) was to allow the "engine and modules [to be] able to publish their configuration settings, as needed." This is currently achieved by creating a map of settings which can be added to and accessed at runtime (see #2757). However, after looking at #3258 and existing config classes, it looks like that settings will only ever be accessed dynamically at runtime -- there shouldn't ever be a need for settings to be published at runtime, since all the settings to be published should be known at the time of writing.
This is evident from the fact that all configs are currently stored as hardcoded classes, with concrete fields as the "settings". FlexibleConfigs, thus, might be a bit too flexible for our uses! This PR thus proposes a hybrid approach, one which addresses all the shortcomings of both the FC and the concrete class approaches while also in my opinion being the most suitable to our use case.
The new approach
The hybrid approach involves using concrete config classes (which are marked as such by inheriting the
Rather than use the newly introduced
Another example using all setting parameters:
All the methods used are static and stateless. They can also be statically imported to make setting declaration easy to read.
The DSL is also fully type-checked and compiler enforced; it is also possible to make some parameters compulsory (as is done for the
Versus concrete classes (currently used)
2 similar comments
1 similar comment
Qwertygiy left a comment
Tested, played around with the values to explore different available options, and with the exception of the "description" key (which is intentionally pending for UI to deal with) everything functioned as expected.