Additions to kconfig_compiler for enum types

[David Jarvie]

On Monday 19 February 2007 00:42:17 Aaron J. Seigo wrote:
> On February 18, 2007, David Jarvie wrote:
> > The reason is because the enums are defined in classes inside the
> > generated class, in a similar manner to how non-global enums already work
> > in generated config classes. AFAICS, some such approach is necessary to
> > allow an enum member with the same name to be defined in multiple enums.
> > For example,
>
> good point. still ways to avoid appending Enum with a typedef, though... =)
>
> in fact, we could always require that enum names are unique, encouraging
> better code through the use of specific and more obvious naming as seen in
> Qt4's usage of enums; or simply prepend the Name rather than putting them
> in a class:
>
> enum Bar { BarNone, BarAll }
> enum Foo { FooPart, FooNone }
...
> prepending the name might look funny in some cases, particularly if the
> programmer is giving the enums good names to begin with.

I don't like having to artificially name elements to avoid duplication like 
this. However, if externally defined enums are introduced (as below), I could 
accept the restriction that elements must have unique names where the enums 
are defined in the settings class, since there would then be the option to 
name the elements independently elsewhere. Ruling out duplicate names, we 
could then simply declare the enums without embedding them in special enum 
classes:

    <choices enum="Bar">
      <choice name="None">
      <choice name="All">
    ...
    <choices enum="Foo">
      <choice name="FooNone">
      <choice name="FooPart">
    ...

would produce:

    class AppSettings : public KConfigSkeleton
    {
      public:
        enum Bar { None, All };
        enum Foo { FooNone, FooPart };

> > > i wonder if it might make more sense to make it so that if you provide
> > > a name for the enum it is assumed that that enum already exists
> > > (leaving it up to the developer to define it somewhere)?
> >
> > Perhaps this might be better implemented as a different extra option.
> > Otherwise, specifically named enums would always have to be defined
> > externally to the settings class. Perhaps that could be specified by
> > another attribute - for example,
> >     <choices enum="Name" type="external">
>
> which makes one more thing for people to learn and results in more code
> paths in the generator, which is ok if there's good reason for it of course
> =) i'm just wondering if there is a real and valid case where it's not
> realistic to have the named enum defined elsewhere. if we can think of one
> great, otherwise we can add it later if needed?

I think that the presence of "::" in the names of enum elements could specify 
that an externally defined enum should be used. An example of an external 
named enum ("Foo" in the class "Class"):
    <choices enum="Class::Foo">
      <choice name="Class::Foo::Element1>

An example of an external unnamed enum (in the class "Class"):
    <choices>
      <choice name="Class::Element1>

An example of external unnamed top-level enum:
    <choices>
      <choice name="::Element1>

> it also pretty much short curcuits much of this conversation as the naming
> and what not of the enums is left up to the developer. KConfigXT is meant
> to bridge between an app and the configuration data (accessing, setting,
> config dialog automation), i'm not sure defining enums is necessarily in
> scope for that?

Enums are already defined automatically by KConfigXT - I don't see that 
extending this to specifying the enums' names is a departure from its 
purpose. It just overrides the default names which are given automatically 
when GlobalEnums=false.

-- 
David Jarvie.
KAlarm author and maintainer.
http://www.astrojar.org.uk/linux/kalarm.html