[omniORB] OmniORBpy & TypeDefs

[Duncan Grisby]

On Tuesday 22 August, jiwils - Jimmy Wilson wrote:

> 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);
> }

You can use a_struct and A interchangeably, as you would expect. The
way I've implemented it, A does inherit from a_struct, but that's not
why you are able to pass an instance of A when an instance of a_struct
is expected. When omniORBpy is expecting a struct, it will accept
_any_ Python object with members with the right names and types. So,
for example, you can do:

  interface I {
    struct S {
      long   l;
      string z;
    };
    void test(in S the_S);
  };

  # Python
  class Foo: pass
  f = Foo()
  f.l = 42
  f.z = "Hello"
  i.test(f)

That will work fine, even though the class Foo is totally unrelated to
the expected struct. In fact, the object doesn't even have to be an
instance:

  class Foo:
      l = 5
      z = "Hi again"
  i.test(Foo)

That passes a Python class where the struct is expected. It still
works because there are members called "l" and "z" with types long and
string.

I'm pretty certain that this behaviour was required by drafts of the
Python mapping specification, but it was removed somewhere along the
line.

Cheers,

Duncan.

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