[omniORB] OmniORBpy & TypeDefs

[Duncan Grisby]

On Monday 21 August, jiwils - Jimmy Wilson wrote:

> Why does the idl compiler generate unusable python classes when the typedefs
> are used in the IDL?  I would like to use the typedefs instead of the names
> in the cases below, but I can't.  Could someone explain why using ELEMENT
> and Elements below would create a problem?  Since a sequence will become a
> tuple or list, I can see that the name Elements is really for ease of use,
> but what about the typedef for the structure?

That's an extremely good question. The answer is that, as far as I can
see, nobody had ever thought of it before. I certainly hadn't. The
Python mapping standard doesn't say anything at all about typedefs,
apart from one sentence which says that all IDL declared types must
have a Python declaration of some sort which can be passed to
CORBA.id(). That's the purpose of the unusable classes.

I don't think it really makes sense for typedefs to things like
sequences and basic types to be usable classes, since the mappings for
those types are not instances of Python classes. However, I do think
it is sensible to map typedefs to structs and unions to classes which
can be used just like the original struct/union definition.

I think the Python mapping specification should be updated to say this
-- I'll post an issue to the OMG. In the mean time, I've implemented
it for omniORBpy anyway. You can get the updated IDL compiler back-end
from CVS, or from the bug fixes patch:

  http://www.uk.research.att.com/omniORB/omniORBpy/bugfixes.html

Until this becomes part of the standard mapping, which hopefully it
will, code which makes use of it should be considered non-portable.

Thanks for the suggestion!

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --