Idea: SkipDirtyOnIdenticalValues WriteConfigFlag for KConfigBase / KConfig
mw_triad at users.sourceforge.net
Tue Jul 15 18:28:54 BST 2008
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.
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.)
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).
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
More information about the kde-core-devel