This PR is an attempt at a new way of managing config options. Previously, options were defined as variants of an enum; now they are defined as static objects of a ConfigOption type. This has several advantages:
Relevant information for each config option is now attached to the config option object itself, rather than being spread around the codebase in static maps. For instance now if you want the name for a config option, instead of calling config_option_names[option] or whatever (and having to go find the header where config_option_names is defined), you can do a much more readable option.name!
There is now a standard list of config options. Previously, enumerating config options or sampling random ones would require math on the enum type, which is dumb. Now we can use standard c++ algorithms to do just about anything. This isn't super relevant on config options, but demonstrates how things will look if we use a similar strategy for other enums where this operation is more common.
While this is all nice, I am still sort of on the fence if this effort is worth it.
Part of #30, but will not necessarily close it.
This PR is an attempt at a new way of managing config options. Previously, options were defined as variants of an enum; now they are defined as static objects of a ConfigOption type. This has several advantages:
config_option_names[option]
or whatever (and having to go find the header whereconfig_option_names
is defined), you can do a much more readableoption.name
!enum
type, which is dumb. Now we can use standard c++ algorithms to do just about anything. This isn't super relevant on config options, but demonstrates how things will look if we use a similar strategy for other enums where this operation is more common.While this is all nice, I am still sort of on the fence if this effort is worth it.