[omniORB] OmniORBpy & TypeDefs

[jiwils - Jimmy Wilson]

Thanks for the fix/update!  However, that leads me to another question,
since in the psuedo-code below type a_struct is the same as type A, how does
the omniORBpy implementation handle the interface methods when I pass type
a_struct or type A to them?  Specifically, what happens when I call
AnInterfaceMethod() with type a_struct and/or AnInterfaceMethod2 with type
A?  Does A inherit from a_struct or is something else going on there?

typedef struct a_struct
{
	...
} A;

interface AnInterface
{
	void AnInterfaceMethod(in A anA);
	void AnInterfaceMethod2(in a_struct ana_struct);
}

Jimmy
-- 
James "Jimmy" Wilson
Software Developer, Acxiom Corporation

-----Original Message-----
From: Duncan Grisby [mailto:dgrisby@uk.research.att.com]
Sent: Tuesday, August 22, 2000 7:50 AM
To: jiwils - Jimmy Wilson
Cc: 'omniORB Mailing List'
Subject: Re: [omniORB] OmniORBpy & TypeDefs 


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 --