On Tue, Feb 14, 2017 at 3:32 PM, Daniel Dekany <[email protected]> wrote: > I propose that in FM3 Configuration should only have two constructors: > > Configuration(Version incompatibleImprovements) > Configuration(Properties properties)
Is it to make sure that users should set the version compatibility explicitly by removing the default constructor? I thought it is a good option with the default constructor because someone always want to use the latest default incompatible improvement anyway with being willing to fix any incompatible template code. Or could it have been dangerous sometimes? > > and that it should not have a setIncompatibleImprovements(Version) > method. Because then it can be ensured that > cfg.incompatibleImprovements is always set first, and not modified > anymore. It's simplifies life considerably, because changing the > incompatibleImprovements changes the default of some settings, so when > in FM2 you change it at some later point, we will have to figure out > which settings were never set with the public setter method, and thus > still hold the initial default (not just something that's identical to > it!), and thus has to be changed. Because Properties are esentially > unordered, we also have to get all of them at once, so that we can > sort them (bring incompatibleImprovements to the first place, sort any > other dependent settings too). +1 > > I also intend to remove `String getSetting(String)`, because it can't > be implemented and has never worked. +1 > > I'm also very inclined to remove setSetting(String) and > setSettings(Properties), as it can lure the user into some ordering > traps. I think Configuration(Properties properties) should be enough, > and then, the user is forced to collect all the properties together > (coming form different source maybe, that's why he collects them), and > the we can do a proper ordering because we have all of them at once. +1 > > Thoughts? I think any operations, which could affect or be affected by invocation orders, should be removed. That will make the code cleaner and safer. Also, if possible, I would like to have an immutable object or representation than the Configuration itself. For example, template#getConfiguration doesn't have to return a mutable object, for instance. But it requires a bigger change, I guess. Cheers, Woonsan > > -- > Thanks, > Daniel Dekany >
