After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 95591 - problem with order of types in typelib for union discriminators?
problem with order of types in typelib for union discriminators?
Product: ORBit2
Classification: Deprecated
Component: IDL compiler
Other Linux
: Normal normal
: ---
Assigned To: ORBit maintainers
ORBit maintainers
Depends on:
Reported: 2002-10-12 07:28 UTC by James Henstridge
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.0

Description James Henstridge 2002-10-12 07:28:13 UTC
In the everything.idl file, we have the following union definition:
        union EnumUnion switch (enum Colour { red, green, blue }) {
        case red: long x;
        case blue: boolean y;

This results in the following types being listed by ORBit_small_get_types()
in the following order:
  - IDL:orbit/test/EnumUnion/Colour:1.0
  - IDL:orbit/test/EnumUnion:1.0

It would be more useful if the two types were returned in the other order.
 In my Python bindings, the following occurs while trying to build stubs
for these types:
  1. get "IDL:orbit/test/EnumUnion/Colour:1.0" typecode
  2. create "orbit.test.EnumUnion" module to hold the enumeration.
  3. put enum values into the "orbit.test.EnumUnion" module
  4. get "IDL:orbit/test/EnumUnion:1.0" typecode
  5. create stub and put it in the "orbit.test" module.

The result is that the orbit.test.EnumUnion module gets overwritten by the
EnumUnion stub.  If the typecodes were returned in the opposite order, then
the enumeration values would become attributes on the EnumUnion stub (as
you would expect).
Comment 1 Michael Meeks 2002-10-14 08:40:39 UTC
I think the order of definition in the IDL file, is quite a good order
to define things in.

Then again the order of container -> children is good as you say; so
... we could insert a special case for this - but we'd need a
regression test to ensure that we didn't slip up on this. Feel free to
commit a patch to fix it.
Comment 2 James Henstridge 2002-10-14 09:47:34 UTC
I am not too fussed if this gets closed as WONTFIX.  I might check if
other language binding authors have an opinion on this.

It looks fairly trivial to make the change in the idl compiler. 
Similarly, it would be pretty easy to work around in PyORBit:
   if tc[i+1]->kind == union and tc[i+1]->discriminant == tc[i]:
       process tc[i+1] first

As far as order of definitions go, the enum is defined at a lower
level in the pass tree than the union, so the definition order depends
on whether you are doing a pre-order or post-order traversal :)
Comment 3 James Henstridge 2002-10-16 14:01:57 UTC
attachment 11591 [details] [review] on bug 95791 includes a patch to change the type
Comment 4 James Henstridge 2002-10-16 14:54:13 UTC
Patch from bug 95791 committed to both HEAD and gnome-2-0 branches.