Re: GConf design goals.

[Dietmar Maurer <dietmar ximian com>]

Havoc Pennington wrote:

> Dietmar Maurer <dietmar ximian com> writes:
> > We have talked a lot about structures until know, but CORBA_any supports
> > more than that. So another example are enumeration types. In bonobo-conf
> > we store enumeration types together with the type info, consisting of an
> > ordered set of names. Two enumeration types are equal if the names and
> > the order are equal.
> >
> > So what are the advantages/disadvantages of that system, as opposed to
> > storing enumeration types as integers? The advantage is that we have
> > strong type checking, so that we can detect incompatible types. We can
> > even try to do automatic type conversions (upgrades) if someone adds an
> > enumeration value in a binary compatible way.
> >
>
> Storing enums as ints is an awful idea, because sysadmins can't make
> heads or tails of it. ("set this setting to 1 to do Y, set it to 2 to
> do Z" is really arcane.)
>
> My suggestion for enums is to store them as nice human-readable
> strings, and GConf has convenience functions to convert enums to/from
> strings. And also of course you need docs on what each enum value
> indicates.
>
> So that's what you want to compare CORBA_any to.

That is what I get if I use CORBA_any, so why should I invent something
else?

- Dietmar