Idea: SkipDirtyOnIdenticalValues WriteConfigFlag for KConfigBase / KConfig

[Matthew Woehlke]

Oswald Buddenhagen wrote:
> On Mon, Jul 14, 2008 at 06:44:08PM -0500, Matthew Woehlke wrote:
>> Oswald Buddenhagen wrote:
>>> almost: what if there is currently a local value written which
>>> matches the default? i think it would be deleted,
>> No, write is not destructive. If the entry already contains 'value',
>> the  write(v,d) call is a no-op. It doesn't change dirty, it doesn't
>> delete  the value already there. Why should it be deleted?
>>
> because otherwise you never know which state it will be in.

It will be in a /consistent/ state. Once written (even if before this 
API existed), it *stays written* unless explicitly unset (deleted), 
which IMO is TRTTD.

> also, the description is (or should be) "ensure that no local value
> exists if it matches the system default" - so changes in the system
> default can take effect.

Terrible idea. Entries should not be deleted just because the saved 
value now matches the default; that would lead to unexpected behavior. 
(This discussion has taken place before, w.r.t. toolbar customization. 
I'm confident this was the same conclusion then.)

Aside from my opinion that trying to heuristically guess if an entry is 
default due to being miswritten as opposed to intentionally written that 
way is a Bad Idea, such an API would be born deprecated, since it isn't 
needed in an app making correct use of write(entry, value, default) that 
starts with a clean config.

> one might add yet another function for a non-destructive write (probably
> as a flag to the destructive one), but i'm not sure what the purpose of
> it would be.

I don't understand what you think is needed. As I see it, we should have 
the two methods I proposed. "Always write", and "write only if doing so 
would change the result of a read".

write(entry, value, default):

Case: read(entry)==value (i.e. entry in local config is non-empty)
Action: do nothing
Rationale: A write would produce an identical config file, therefore it 
is unnecessary. Skip setting dirty for the same reason we would do so in 
write(entry, value). Whether value==default is irrelevant, since this 
should not cause a deletion, as explained above.

Case: read(entry,default)!=value
Action: write new value
Rationale: Either value!=default, or else the user changed value to 
something which happens to be default. Either way, the new value should 
be written. (Note that 'reset to defaults' would use delete(entry), not 
write(...). See above.)

Case: read(entry,default)==value
Action: do nothing
Rationale: The stated objective is to not write back values == default 
when the entry is presently unset.

In the last case, one can debate if the value should be written if it 
isn't the default, but is the same as the read value from an inherited 
config. My (current) opinion is that this case should not be considered 
as different from the case when the entry is unset; it still represents 
that the value read was not changed and therefore should not be stored 
(where writing would effectively override the mechanism that provided 
the value initially).

-- 
Matthew
I don't see what C++ has to do with keeping people from shooting 
themselves in the foot.  C++ will happily load the gun, offer you a 
drink to steady your nerves, and help you aim. -- Peter da Silva (from 
cluefire.net)