lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Resetting hard-coded defaults before loading 'configurable_set


From: Greg Chicares
Subject: Re: [lmi] Resetting hard-coded defaults before loading 'configurable_settings.xml'
Date: Fri, 17 Nov 2006 05:18:14 +0000
User-agent: Thunderbird 1.5.0.4 (Windows/20060516)

On 2006-11-14 14:57 UTC, Evgeniy Tarassov wrote:
> On 11/10/06, Greg Chicares <address@hidden> wrote:
>> Evgeniy--In 'gnome-xml-branch',
>> configurable_settings::load_from_file() has a section that
>> begins with this comment:
>>
>>     // first of all reset all members to default values
>>
>> I understand what it does, but would like to understand why.
>> What problem would occur if we didn't do this?
> 
> Oh, i should have added a comment to
> configurable_settings::load_from_file method.
> 
> IMO when we load settings from the xml file we should not care about
> which particular values are specified and which are not. If a value is
> absent in the xml file we should (IMHO) treat it as if the value was
> present and equal to its default value. Therefore (for me) when code
> reads values from the xml file (via load_from_file method) we should
> ensure that it sticks to the logic mentioned above.

I believe that I didn't port that to HEAD, and that the program still
works correctly without it--if we don't save missing elements (giving
them their default values), then, when the saved file is later loaded,
the program supplies the default values. One way may be nicer than the
other, but I think neither yields incorrect behavior.

And, as has been subsequently discussed, this code was written only
because I overconstrained the problem in a way that we should revoke,
so it's not important to make it nicer now. That's what I was thinking
when I ported it, and now I guess we all agree on the future direction.

> Currently this method (load_from_file)  is called from the constructor
> only, but i think we should be able to call it from any other place
> too, thats why it has to reset to defaults. Otherwise the following
> will not stand:
[snip hypothetical case]

I believe that we needn't worry about that potential usage, because
we've revoked that part of the specification, so we'll never use it
that way.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]