orbit-python-list

[Orbit-python-list] Implementing proprietary extensions

[Jason T. <ta...@li...>]

Right now ORBit-Python implements a few extensions, such as transparent
accessors (through __setattr__ and __getattr__).  These extensions don't
really break the spec since they needn't be used at all.  However
recently I've had a number of requests to implement coercion between
CORBA.Any and Python objects.   This will obviously break the spec in
the case of CORBA.Any return values.

So I was wondering what the best approach would be to enable such
proprietary enhancements in ORBit-Python.  I see 3 different "modes"
that would change the way the module behaves:

    * strict: Enforce strict adherence to the mapping specification.
      This will ensure compatibility with other specification-compliant
      ORBs.
    * extended: a superset of the strict mode.  Features that extend the
      specification, like transparent accessors or certain coercions,
      become available.  This would be the default mode
    * enhanced: features that break the spec become available, like
      coercing from CORBA.Any to Python objects.

The question becomes: what is the best way to select a mode?  In some
cases, the mode changes the actual semantics of the code.  Code between
enhanced and extended modes would work differently.  Python 2.1 uses a
__future__ module that is used to enable things like nested scopes.  My
inclination is to use a similar approach:

    from ORBit import enhanced

or

    from ORBit import strict

Any comments or thoughts on this approach?

Cheers,
Jason.

[Orbit-python-list] Re: [DO-SIG] Implementing proprietary extensions

[Martin v. L. <ma...@lo...>]

> Right now ORBit-Python implements a few extensions, such as transparent
> accessors (through __setattr__ and __getattr__).  These extensions don't
> really break the spec since they needn't be used at all.  However
> recently I've had a number of requests to implement coercion between
> CORBA.Any and Python objects.   This will obviously break the spec in
> the case of CORBA.Any return values.

You could offer accepting arbitrary values as in parameters, and
produce CORBA.Any objects for out parameters. This is probably what
most users want, since

  foo(Any(CORBA.typecode(MyStruct)), MyStruct(1,2,3))

is annoying, whereas

  r = foo().value
  print r.field

is acceptable, IMO.

As Duncan explains, you'll need to document what typecode ORBit infers
when it gets a Python object. That is relatively easy for the
primitive types, but can get involved for the constructed ones.

>     * strict: Enforce strict adherence to the mapping specification.
>       This will ensure compatibility with other specification-compliant
>       ORBs.

In particular, it will insure portability of applications. Strictly
conforming applications will also run in your extended mode; they just
won't use any extensions.

I wonder how many people would actually use the strictly conforming
mode. Most people will know when they deviate from the spec, and make
a choice whether that is acceptable. When porting applications, you'll
find problems even if you had been passing the strict mode: the spec
may have been interpreted in different way by implementors, or there
may be plain bugs or missing features in the implementations.

So the best way to achieve portability is to actually do the
porting. Then, the spec should be good enough to allow for portable
code in all applications.

>     * extended: a superset of the strict mode.  Features that extend the
>       specification, like transparent accessors or certain coercions,
>       become available.  This would be the default mode

Yes, that is what most CORBA implementations (in any language) provide.

> Any comments or thoughts on this approach?

As I've mentioned in another message: CORBA has its own policy
mechanism, which can be used to offer choices.

Regards,
Martin