Global state: Settings used throughout the code

[sjunges]

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

• [ ] Api
• [ ] Builder (Requires dont fix deadlocks as a builder option)
• [x] Generator
• [ ] Modelchecker
• [ ] Solver
• [ ] Storage
• [ ] Utility

For utility, the difficult cases seem to be:

• [ ] ProgressMeasurement (settings to determine whether to output something, relates to https://github.com/moves-rwth/storm/issues/272)
• [ ] ConstantsComparator (settings to determine the precision to use)
• [ ] VectorHelper (settings to determine whether to use TBB), relates to https://github.com/moves-rwth/storm/issues/133

[sjunges]

For utility, the difficult cases seem to be: [ ] ProgressMeasurement (settings to determine whether to output something) [ ] ConstantsComparator (settings to determine the precision to use) [ ] VectorHelper (settings to determine whether to use TBB)

I think that in these three places, the use of a global state is acceptable.

[sjunges]

Update: