In FM2 we have these things called custom attributes, which are unrestricted key-value pairs that the user can associate on all 3 configuration scopes: Configuration, Template, and Environment. The key can be anything, like an enum or a String.
In FM3, when earlier I have refactored it to use immutable configuration in all 3 layers, I ran into a problem; in FM2 custom attributes are mutable anytime in all scopes by design. That's because one application of them was holding scoped custom state variables. So much earlier, I have removed that functionality from attributes, made the Map of attributes immutable as FM3 demands it, and to fulfill the lost functionality I have added a new interface called CustomStateScope and all scopes implement that. So now that custom attributes doesn't server that use case anymore, we probably should rename custom attributes to custom settings. They are pretty much like the other configuration settings now (i.e., they are only mutable in builder classes an in Environment), except that they are defined dynamically (using a Map) by the user. Apart from the name, the behavior of the API would mirror that too, that is, as for all settings we have setXxx(value)/getXxx()/isXxxSet() methods with the documented semantics, similarly we will have setCustomSetting(key, value)/getCustomSetting(key)/isCustomSettingSet(key) methods. The `key` parameter is needed as we can't have the name of the custom attributes in the method names (i.e. in place of the Xxx). BTW, the `key` is Serializable so that it can be stored in Exception-s. (I wonder if it should be String... but I guess using enum-s for keys is more efficient, so I don't want to remove that possibility.) Anyone opposes this? -- Thanks, Daniel Dekany
