Re: [Orbit-python-list] Implementation questions

[Duncan G. <dg...@uk...>]

On Friday 18 August, Jason Tackaberry wrote:

> First, for interfaces that are not encompassed in modules, I notice that
> you use a _GlobalIDL module.  I didn't see this point addressed in the
> mapping specification, so I assume this is a solution specific to omniORBpy?

Well, the specification actually says

  "Other global definitions (except modules) appear in a module whose
   name is implementation dependent. Implementations are encouraged to
   use the name of the IDL file when defining the name for that
   module."

As you say, omniORBpy uses "_GlobalIDL", not the name of the IDL file.
The second sentence I've quoted above was not in drafts of the
mapping, so I followed the precedent set by Fnorb, which also uses
_GlobalIDL.

There is also a technical reason for not doing what it says. I should
probably submit an issue about it to the OMG. Consider two IDL files:

  // a.idl
  struct S {
    long l; string z;
  };

  // b.idl
  #include "a.idl"
  interface I {
    S op();
  };

Now, if we follow the "encouraged" mapping, the definition of struct S
lives in Python module "a", while the definition of interface I lives
in Python module "b". But the definition of interface I relies on the
definition of struct S, which it expects to be in the same module. The
advantage of using a fake module name like "_GlobalIDL" is that
definitions which are in the same IDL scope are always in the same
Python scope.

omniORBpy's IDL compiler has an option to change the global module
name, so you can force it to follow the "encouraged" mapping if you
want to.

> The way I would want to approach the problem is to use the same scoping
> rules as regular modules.  So,
> 
> interface Echo {
>    // ...
> };
> 
> I would favor simply:
> 
>    import Echo

That can't work, since the result of import has to be a Python module.
In the example of an interface declared at global scope, that doesn't
necessarily matter (since the Python mapping for interfaces is
flexible enough that Echo could be a module), but with the struct in
a.idl above, the mapping says that S must be a Python class. I don't
think you can reconcile that with the use of import for things in
global scope.


> Also, the specification seems a little vague about inheritance vs.
> delegation.  In particular, I'm not sure if implementing interfaces
> through inheritance is required while delegation is optional, or if you
> can get away with one or the other (or both).  I chose delegation because
> inheritance was just too tricky.  Deriving a class object created from C
> is impossible, and achieving that functionality would require using something
> like Jim Fulton's ExtensionClass.  Delegation was the clear winner for the
> dynamic IDL approach I took.  So, if I want to adhere to the specifications,
> is implementation through inheritance required, strongly recommended, or
> optional?

I had always read the mapping as saying that inheritance was
mandatory. However, looking at it again, it does indeed look like it
makes it optional. In fact, it seems to make everything about the
server side mapping optional, which is a bit silly. I think the
_intention_ of the mapping is that inheritance is mandatory, but I'm
not at all sure. At the very least, I would say that it's strongly
recommended. Perhaps you should submit an issue to the OMG (email to
is...@om...) to get it clarified. If you email to do...@py...
too, the people who wrote the mapping will be able to comment.

If the mapping is intended to allow delegation, it fails to specify
the naming scheme for the tie class (or types in your case). That
should be standardised, just as the scheme for skeleton class names is
standardised.

If it turns out that inheritance _is_ mandatory, I don't think it will
be too much of a problem for you. The skeleton class does not have to
be very complicated. My guess is that it wouldn't be too hard to
dynamically create a new class with PyClass_New(), and fill in the
bits you need with the PyObject_... functions, all from C code.

If that's too hairy, you can write Python functions to create classes
for you, and call those functions from C code. omniORBpy does
something similar when it is unmarshalling TypeCodes for structs and
unions which is does not have stubs for -- the C++ code calls the
Python omniORB.createUnknownStruct() and omniORB.createUnknownUnion()
functions. Those functions create new classes and return them back to
C++.

I'm afraid you're discovering that complying with standards is a
rather painful process...

Cheers,

Duncan.

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