[omniORB] type checking
Duncan Grisby
duncan at grisby.org
Mon Jul 7 11:20:29 BST 2008
On Friday 4 July, "Ridgway, Richard \(London\)" wrote:
> In a function on the server this tells you the desired return
> parameters: self._omni_op_d[sys._getframe().f_code.co_name][1]
>
> I can't quite put it all together with the decorator as I don't
> understand how the omniorbpy typecodes work. A string return is fine for
> idl sequence<octet> - but how do I know that?. I can get the typecode of
> my returning value, just don't know how to test for equivalence. There's
> probably a call hidden away in omniorb, I just can't see it. Duncan?
The code in omniORBpy that does the type checking is all in C++, mostly
in pyMarshal.cc. There isn't any Python code to do it.
The type descriptors are basically tuple representations of the CORBA
TypeCodes. Exactly what's in each tuple is documented in the comments in
pyMarshal.cc. e.g.:
static void
validateTypeStruct(PyObject* d_o, PyObject* a_o,
CORBA::CompletionStatus compstatus,
PyObject* track)
{ // class, repoId, struct name, name, descriptor, ...
Which shows (with a little interpretation) that in the descriptor tuple
for a struct, there's the Python class, then the repository id, then the
struct name, then a repeating list of member names and type descriptors
for the members. All the tuples start with the TypeCode kind, which
isn't listed in the comments. Simple types with no extra data are
represented as just the integer TypeCode kind, rather than a tuple.
Does that make sense?
Cheers,
Duncan.
--
-- Duncan Grisby --
-- duncan at grisby.org --
-- http://www.grisby.org --
More information about the omniORB-list
mailing list