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

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

> On Wednesday 11 April, Jason Tackaberry wrote:
> 
> > 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.
> 
> Interesting. I can see how it's easy to return Python objects when
> unmarshalling an Any, but how would you do the marshalling side?  How
> can you tell if something like "hello" is meant to be a string or a
> sequence<octet>, or a sequence<char>, or a 5 element array of octet or
> char?

OTOH, looking at it from a compatibility perspective, allowing
additional (types for) values as parameters is an extension to the IDL
mapping, thus less troubling than returning the "unpacked" value.

> Personally, I don't think that's very nice at all. I don't like the
> __future__ thing either. I think it's confusing to re-use the import
> mechanism to do something altogether different.  I'd be inclined to go
> for something like
> 
>   import ORBit
>   ORBit.mapping_mode(ORBit.ENHANCED)
> 
> or perhaps
> 
>   ORBit.mapping_mode("enhanced")

Isn't that what policies are meant for? So I'd expect something like

 p = orb.create_policy(ORBit.ENHANCED)
 orb._set_policy_override([p],CORBA.ADD_OVERRIDE)

A specific function is easier to use, of course.

Regards,
Martin