GNOME Bugzilla – Bug 93725
ORBit typelibs do not expose constants
Last modified: 2006-12-18 09:58:57 UTC
I was talking with Michael on IRC yesterday, and we realised that typelibs do not expose constants. I have been (re)writing some Python bindings for ORBit2 to use typelibs (instead of parsing IDL, as it currently does ...), and noticed that I couldn't get at this sort of information. I would like to be able to get the short name of the constant, it's value, and know which module to store the constants in. The first two could be acheived with a list of (name, corbaany) pairs. I don't know how it would be best to represent which module they belong to though.
Hmm .. we should really have a representation of modules as well, and then a list of constants in both ORBit::IModule and ORBit::IInterface as well I suppose. Btw James - on the gen-imodule branch of ORBit2 there is a runtime generator of typelibs. I need to fix some issues with the API and get it merged into HEAD.
Currently my code is munging the repo_id's from the typecodes to work out where to expose a stub, which is probably not the best solution ...
One other thing that the current typelib framework doesn't seem to handle is typelibs that build on top of other ones. For instance, consider a Bonobo component that provides a custom interface built on top of Bonobo.Unknown (and maybe using some other types defined in bonobo). Its typelib should probably depend on the "Bonobo" typelib. At the moment, typelibs can really only depend on stuff defined in libORBit2 -- everything else has to be defined in the typelib. I don't know how easy this would be.
Has this changed in the last four years?
Yes, it got fixed I think: CORBA_sequence_CORBA_TypeCode * ORBit_small_get_types (const char *name);