[Kde-bindings] possible conflicts in enums
Richard Dale
rdale at foton.es
Mon Sep 7 09:47:45 UTC 2009
On Monday 07 September 2009 10:25:02 am Petr Vanek wrote:
> hi all,
>
> we are facing some special problem here. Enums are handled as integers
> (numerical values) in our langugae bindings. Fair enough and easy to
> operate with it - except it's undeterministic in some cases:
>
> Let's take for example these enums
> enum Qt::GlobalColor
> enum Qt::PenStyle
>
> and available constructors (Qt):
> QPen ( Qt::PenStyle style )
> QPen ( const QColor & color )
>
> If I use it in special case (pseudocode)
>
> // "enum", but it's just an alias for 3
> foo = Qt::DotLine
> // then call
> pen = new QPen(foo)
>
> so it's unclear which constructor to call. Just because Qt::DotLine
> equals Qt::white in this case.
>
> Question: is there any way how to get a "enum type" from smoke? How to
> do it? We can create real enums for our language then.
>
> If there is not such feature - can it be done? I mean: are you
> interested in it, or should we maintain it only in our codebase?
In QtRuby a Qt::Enum value is returned for enums. I don't think we need to add
anything to smoke because converting from the long on the smoke stack to a
Ruby Qt::Enum or whatever is needed for other languages, is something than a
language specific marshaller can do. The enum 'MethodFlags' in smoke.h has a
value mf_enum, and so it is easy to know if the method being called is
returning an enum value, and the stack union ha an 's_enum' variant:
enum MethodFlags {
mf_static = 0x01,
mf_const = 0x02,
mf_copyctor = 0x04, // Copy constructor
mf_internal = 0x08, // For internal use only
mf_enum = 0x10, // An enum value
mf_ctor = 0x20,
mf_dtor = 0x40,
mf_protected = 0x80
};
In QtRuby, marshall_basetypes.h this code does the conversion:
template <>
void marshall_to_ruby<SmokeEnumWrapper>(Marshall *m)
{
long val = m->item().s_enum;
*(m->var()) = rb_funcall(qt_internal_module, rb_intern("create_qenum"),
2, LONG2NUM(val), rb_str_new2( m->type().name())
);
}
-- Richard
More information about the Kde-bindings
mailing list