On Sunday 18 February 2007 22:55:26 Aaron J. Seigo wrote:
> 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.
The method signatures I've given above hide the fact that the enums are
members of the generated class. Fully qualified, they would read
void AppSettings::setFoo( AppSettings::EnumFoo::type v );
AppSettings::EnumFoo::type AppSettings::foo();
> > 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.
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,
class AppSettings : public KConfigSkeleton
{
public:
class Bar1
{
public:
enum type { None, All };
};
typedef Bar1::type Bar1Enum;
class Bar2
{
public:
enum type { Part, None };
};
typedef Bar2::type Bar2Enum;
....
};
This allows None to be used in more than one enum without clashing. It would
be nice not to modify the enum names by appending Enum, but the enums' class
names and their typedefs need to be different. Under this scheme, individual
enum members can be referred to as e.g. AppSettings::Bar1::None, while the
enum type would be AppSettings::Bar1Enum.
> 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)?
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">
> > I attach a patch - is it okay to apply?
>
> it would be nice if your patch followed the kdelibs coding style =)
I've tried to follow the style of the existing code.
--
David Jarvie.
KAlarm author and maintainer.
http://www.astrojar.org.uk/linux/kalarm.html