[Orbit-python-list] Re: [DO-SIG] Implementing proprietary extensions
Status: Inactive
Brought to you by:
tack
|
From: Martin v. L. <ma...@lo...> - 2001-04-12 17:14:53
|
> 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
|