Additions to kconfig_compiler for enum types

[Aaron J. Seigo]

On February 18, 2007, David Jarvie wrote:
> I'd like to add two extra options to kconfig_compiler for enum type items.
> The aim of the changes is to make it more straightforward for application
> code to use enums rather than int values when handling enum config options.
> Using enums is more type-safe, so it should encourage safer coding. Note
> that the proposed changes are backwards compatible - existing .kcfg and
> .kcfgc files and their generated code will be unchanged.
>
> 1) the option to use enum types instead of int for the parameter of the
> manipulator and the return value of the accessor. This would be specified
> by the use of a new option in the .kcfgc file, "UseEnumTypes=true". This
> option would be ignored unless GlobalEnums=false is also specified. The
> method signatures would become
>     void setFoo( EnumFoo::type v );
>     EnumFoo::type foo();
>
> This option removes the need for application code to cast from int to enum.

why not put the enum's in the generated class itself? so if the generated 
class name is defined as, say, AppSettings in the kcfgc file, then you'd get 
AppSettings::FooType or ::FooEnum. 

> 2) the option to specify the name of the enum. The reason for this is that
> generated enum type names can currently be rather long and cumbersome, and
> the new option would allow shorter enum names to be used, and possibly for
> the names to be more understandable in the context of the application code.
> Again, this option would be ignored unless GlobalEnums=false is specified.
> The option is specified using an optional parameter to the <choices>
> element: <choices enum="Bar">
>
> When this option is used, the generated enum class would be "Bar". A
> typedef will also be generated:
>     typedef Bar::type BarEnum;
>
> When used together with UseEnumTypes=true, the method signatures would
> become: void setFoo( BarEnum v );
>     BarEnum foo();

why add "Enum" to the name if the name is being explicitly defined? the 
developer should be able to pick a name that doesn't conflict with other 
symbols.

and what about the use case where the enum already exists in another class? 
that's fairly common and would be nice to be able to name the enum to be 
used.

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

> I attach a patch - is it okay to apply? 

it would be nice if your patch followed the kdelibs coding style =)

> If so, I'll also amend the 
> KConfig_XT tutorial on developernew.kde.org for KDE 4.

huzzah!

-- 
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/ea8d578e/attachment.sig>