Re: [Orbit-python-list] Uploaded patch

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

On Tuesday 15 August, Jason Tackaberry wrote:

I was the one who asked about standards compliance in
comp.lang.python. I'm also the author of omniORBpy, which fully
adheres to the mapping. I think the value of the standard is being
severely weakened by the fact that none of the other Python ORBs
support it. I believe that this disagreement between ORBs will put
people off from using Python with CORBA.

Please don't interpret this email as an attempt to get people to use
omniORBpy. I would genuinely like to see ORBit-Python improve in all
ways, including its standards support. The more good Python ORBs there
are, the more incentive there is for all of us to keep improving them.

> I do address this (somewhat) in my thesis document.  In short, yes I do
> wish to make the mappings OMG compliant where it makes sense.  I seem to
> recall some of the mappings in the specification not making sense for the
> approach I took (dynamic IDL).

The only thing I can see that potentially causes difficulty is the
mapping requirement that IDL module "M" can be accessed from Python
with "import M". One way around this is to write small modules which
do nothing but call CORBA.load_idl(). A simple IDL compiler fragment
which just wrote such modules would comply with the mapping
requirement, while keeping the general dynamic IDL approach.

> Some things will be easy to implement, such as the attribute accessor
> pairs.  I read some discussions on why one should favor accessor functions
> versus operator overloading, but these arguments just don't apply to
> ORBit-Python because of its dynamic approach.  I do discuss this in my
> thesis paper, so it may be worth reading (the latter two chapters) for
> my rationale.  In the end, I wish to have both methods.  I can imagine
> there are pretty good arguments for just using the accessor pairs, but
> the current method is just damn cool and just as efficient.

I've read your thesis, and I think you have slightly missed the
intention of IDL attributes. Attributes in IDL are explicitly _not_
simply data members of the object -- they are a shorthand for
specifying a get/set pair of operations (or just a get in the case of
readonly attributes). It should be possible for a servant to do
anything it likes in response to the getting or setting of an
attribute. That is not (easily) possible to do with the current
ORBit-Python mapping.

It is also my personal opinion that it's confusing to the programmer
that an innocent-looking piece of Python code like

  obj.value = 10

involves a remote call, and can raise any of the CORBA system
exceptions. I think it's far better to make it look like what it is: a
method invocation.

Cheers,

Duncan.

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