On Sun, May 28, 2017 at 4:29 PM, Daniel Dekany <[email protected]> wrote: > 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?
No objection! All sound like a plan to me! Regards, Woonsan > > -- > Thanks, > Daniel Dekany >
