Additions to kconfig_compiler for enum types

[Aaron J. Seigo]

On February 18, 2007, David Jarvie wrote:
> On Sunday 18 February 2007 22:55:26 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 }

this would allow one do:

AppSettings s;
AppSettings::Bar b = s.bar();
s.setBar(AppSettings::BarNone);

which is a bit less typing than AppSettings::BarEnum and 
AppSettings::Bar::None.... 

prepending the name might look funny in some cases, particularly if the 
programmer is giving the enums good names to begin with.

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 =)

> AppSettings::Bar1::None, while the enum type would be
> AppSettings::Bar1Enum.

this would be a bit more obvious without the typedef imho so the signature was 
setFoo(Foo::type f); or even better setFoo(Foo f) ?

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

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?

> > it would be nice if your patch followed the kdelibs coding style =)
>
> I've tried to follow the style of the existing code.

we're slowly bringing code in line with the kdelibs coding style as we modify 
it. things like the indent for methods like enumType which are new and using 
{}s appropriately shouldn't make the rest of the code there more ugly and 
brings it closer to being the proper style... consistent use of spaces 
between ()s would also be cool.

obviously this is less important than the functionality ;)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070218/4c3e16fc/attachment.sig>