Additions to kconfig_compiler for enum types

[David Jarvie]

On Sunday 18 February 2007 22:55:26 Aaron J. Seigo wrote:
> On February 18, 2007, David Jarvie wrote:
> > On Sunday 18 February 2007 22:55:26 Aaron J. Seigo 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 }
... 
> if the enums are local to the class, then there's no reason they can't have 
> unique names imho. and if they aren't local to the class (the type="external" 
> case below), they'll already be namespaced uniquely =)

As things stand, I don't like the restriction that enum elements have to have
unique names when they are defined inside the settings class. However, if
the ability to use external enums is added (as below), I'd accept this
restriction. Then, there would be no need to use encapsulating classes to
declare the enums, and prefixing/suffixing enum type names with "Enum" or
whatever would be unnecessary. This would make using the enum naming
facility more straightforward.

> > > 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?

A better scheme might be to say that if the enum name includes the character
string "::", the enum is defined externally to the settings class. For example,
an enum Xyz defined in class Ext2 would be declared:
    <choices enum="Ext2::Xyz">

An example of an unnamed enum in class Ext2:
    <choices enum="Ext2::">

An example of a top level enum Abc:
    <choices name="::Abc">

A top level unnamed enum would always be:
    <choices name="::">

In all cases, the enum elements would be declared in the normal way:
    <choice name="Element">

> 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 with generated names when
GlobalEnums=false. So all that is being added here in relation to non-externally
defined enums is to be able to control their names better.

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