Re: Re: Why all the different string types?

kaczoroj wrote:
> Guy,
> 
> By now I have made up my mind and I am altering the code to use std::
> string as we speak. That will eliminate needless implememntations of 
> string functionality all other again at the price of writing some 
> utility functions to make the std::string actually usefull ;)

Great!  Thanks for taking the lead on that.

> 
> Having that we can see what to do next. 
> 
> 
>>Instead of having individual getters and setters for 
>>each preference, there could be a single SetBoolean, 
>>SetInteger and SetString; 
> 
> 
> Current persistency implementation is not too bad actually. If we are 
> going to use the "named" settings storage we will loose type safety. 
> It is also quire error-prone as you are just one typo away from not 
> getting what you want. It's also hard to track the changes in the 
> names etc... 

The typo issue is easily resolved.  You can have an association between 
a list of allowed values (enum, array, whatever) and an associated 
character string that gets persisted.  For example:

CONSOLE_FONT ==> "P_ConsoleFont"

The API would only take the constant values, something like 
setString(CONSOLE_FONT, "courier 10").  The actual names would only be 
stored on one place, so tracking changes would be trivial.

I think addressing type safety is doable without too much effort.  Once 
I get a reply from Jens to help me understand the specific issue he is 
addressing, I can think about this a little more clearly.  Hmmm, just as 
I was about to click the "send" button, I had a late-breaking thought 
about type safety.  If we come up with a list of allowable types, like 
P_TYPE_BOOLEAN, P_TYPE_STRING, P_TYPE_INTEGER, etc, then when a method 
like setBoolean(ALWAYS_USE_CVSROOT, true), we could automatically make 
sure that ALWAYS_USE_CVSROOT is of type P_TYPE_BOOLEAN.

The current implementation works, but adding a setting shouldn't require 
so many changes.  Think about Windows INI file handling as an example. 
You don't have to declare a separate variable for each individual 
setting and then use a separate setter and getter for each one.

> But the most troublesome is that current implementation is deeply 
> entrenched and works well with the code we have. It would be a huge 
> task to change that now, not to mention that we need to migrate data 
> from the old to the new storage format so we would have two systems 
> operational. 

If we are only changing the code implementation, we wouldn't necessarily 
have to change the on-disk representation.  But your point about having 
to change code is valid.  I'm not sure it would be any more drastic than 
changing our string implementation.  Besides, CPersistentBool seems like 
a kludge that needs fixing, regardless of the effort.

> The idea of making settings more "local" so that MDI can be better 
> supported is probably more realistic. 

If we are to undertake that, then changing the framework at the same 
time might make sense.

-- 
Guy Rouillier


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/cvsgui-dev/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/