[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