As a midterm goal, it would be good to clarify the use of command line settings throughout the code. For this, we have adapted environments as a more transparant solution. The following image shows, however, that we still have quite a way to go. (This simply searches for the occurrence of "settings", I have a longer more detailled list somewhere). Occurrences of settings in the settings is clear, and in the environment constructor is something that could be easily resolved.
To be clear: a limited use of a global state is fine, but right now there are too many variables occurring at too many places. I think that a global state object should have a limited set of well documented variables and that settings should be a CLI thing.
Lets focus on the easier targets first
For utility, the difficult cases seem to be:
As a midterm goal, it would be good to clarify the use of command line settings throughout the code. For this, we have adapted environments as a more transparant solution. The following image shows, however, that we still have quite a way to go. (This simply searches for the occurrence of "settings", I have a longer more detailled list somewhere). Occurrences of settings in the settings is clear, and in the environment constructor is something that could be easily resolved.
To be clear: a limited use of a global state is fine, but right now there are too many variables occurring at too many places. I think that a global state object should have a limited set of well documented variables and that settings should be a CLI thing.
Lets focus on the easier targets first
For utility, the difficult cases seem to be:
STORM_PRINTvsSTORM_LOG_INFOoutside CLI #272)