Re: [Orbit-python-list] orbit-python and __setattr__ overloading

[Marcelo CB <co...@as...>]

Hi Jason,

You're right, after Roland's post I realized that the right thing to do
was to overload the _set_'s and _get_'s instead of __setattr__ so I don't
have to check if the attributes being changed are critical to the
persistency or not. I just override the correct arguments.

thanks.

On Tue, 30 Jan 2001, Jason Tackaberry wrote:

> > Hi,
> 
> Hi Marcelo,
> 
> > is it possible that orbit-python would set the attribites through
> > __setattr__ the way I though so  could overload it ?
> 
> Keep in mind that ORBit-Python's transparent handling of attributes is
> not really part of the mapping spec, and there are some good reasons to
> avoid using them (such as explicitness).  I personally like the idea of
> transparency, though.
> 
> At the moment, ORBit-Python won't call the servant's __setattr__ and
> __getattr__ functions on invocation of one of the attribute accessor
> functions.  It obviously should.  I expect that's an easy thing to fix,
> so I'll do that right now.  (Stay tuned.)
> 
> As an alternative, you could override the accessor function, which is
> what you're supposed to do anyway (if you want to be compliant with the
> mapping spec).  So for example:
> 
> interface Foo {
>    attribute string mystr;
> };
> 
> Then in the implementation:
> 
> class Foo_Impl(Global__POA.Foo):
>    def _set_mystr(self, val):
>       print "Setting mystr attribute"
>       self.mystr = val
> 
>    def _get_mystr(self):
>       print "Getting mystr attribute"
>       return self.mystr
> 
> Anyway, I'll commit a fix for ORBit-Python to call __setattr__ and
> __getattr__ for the servant in the absence of an implemented accessor
> function.
> 
> Cheers,
> Jason.
> 
> _______________________________________________
> Orbit-python-list mailing list
> Orb...@li...
> http://lists.sourceforge.net/lists/listinfo/orbit-python-list
> 

Marcelo Corbani de Barros                   co...@as...
Async Open Source Development - Brasil