Re: GConf design goals.

[Havoc Pennington <hp redhat com>]

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.

> And I can see no disadvantage, simply because I can still store
> enumeration values as integers.

By that logic, you should add any feature to any library, as long as
the current features still exist. ;-)

"I see no disadvantage to putting an LDAP server in GTK, you can still
use the GUI toolkit part." ;-)

Havoc