Re: [AD] Allegro 5 new config routines, alpha 1

[Grzegorz Adam Hankiewicz <gradha@xxxxxxxxxx>]

On Fri, Feb 08, 2002 at 07:15:58PM +0100, Angelo Mottola wrote:
> I'll summarize our current problem here: we have the following decision
> to take. We can:
> 
> 1) Store variables in memory using their real type. An int is stored as
> an int, etc.
> Pro: fast access to the variable once it's already in memory, as no type
> conversion is involved.
> Con: the data type is apparently (if we don't find a way to solve it)
> lost when saving the variables to disk.
> 
> 2) Store variables in memory all as strings. This is the current way
> Allegro does the job.
> Pro: simplifies manual editing of the config files, as you don't have to
> worry about what variable is what.
> Con: small performance loss when accessing the variables in realtime,
> due to the type conversion.

Maybe a mix can be a good thing after all: whenever a config file is
loaded, it's kept in memory as strings. Now, when the program requests
some variable, the function name (get_int, get_float, etc) will tell the
config routines how to convert the string. The converted value can be
catched and returned in subsequent calls, as long as the function used
to retrieve the value is equal to the cached value type.

Hence, you mix the pros of fast access after the first time, and the
pros of not worrying the type of variables. Say, even if the user types
some string in a variable my program will read as integer, no matter
how clever your autodetection mechanism is, I will keep reading/saving
the integer ignoring the string the user typed.

I personally dislike the autodetection thing: if it can't work 100% of
the times, sooner or later it will get in the way. Also, it doesn't fit
very well strong typed languages, it would be better in languages like
python where the variable you are manipulating can be just anything as
long as it can be converted/stored.

Anyway, since C is strong typed, and programs are going to request
variables in a specific type, maybe it would be good to "strong type"
the variables in the .cfg files too so that clever users know what kind
of value does the program expect. Examples:

player_name[string] = All your emails belong to us
player_age[integer] = 34
hit_average[float] = 34.12

Since the characters '[]' could be used for other things too,
it could be a good idea to restrict the range of characters
that can come in the name of the variable. Take a look at
http://www.xiph.org/ogg/vorbis/doc/v-comment.html.  They have the
advantage that tags are rarely going to need localization, but it all
makes it easier to parse correctly a .cfg file.

One thing I've never figured out how to do properly, both for the program
and the user, is how to support multiline strings in variables in such
a way that it's difficult for the user to screw the validity of the
file. Any ideas on that?

Another thing: what encoding will .cfg files use? utf8? Other versions
too?  If the config routines should support .cfg files in other encodings,
I would suggest an obligatory first line stating the encoding of the file.

-- 
 Grzegorz Adam Hankiewicz   gradha@xxxxxxxxxx   http://gradha.infierno.org/