[Pyobjc-dev] Re: deallocating python/objc hybrids

[Ronald O. <ous...@ci...>]

On Sunday, Dec 15, 2002, at 21:33 Europe/Amsterdam, bb...@ma... wrote:

>
> On Sunday, Dec 15, 2002, at 14:56 US/Eastern, Ronald Oussoren wrote:
>> After I checked this in it came to my mind that changing the class of 
>> remaining half of the object might be a cleaner way to do. Currently 
>> the program will fail because of unimplemented methods if [super 
>> release] calls methods that were overridden in Python. As the user 
>> cannot do anything about this just changing the type of 'self' might 
>> be more usefull ('self->isa = self->isa->superclass;' instead of the 
>> if-statement in the code above).
>
> Would it be possible to mark the object such that attempts to invoke 
> methods on the object that were formerly implemented on the python 
> side behave as messages-to-nil?
That would be possible, but would probably have bad side-effects. These 
method-calls are probably done to do some cleanup (deallocating 
resources etc.). Calling the super-class implementation is probably the 
best way to achieve this.

>
> Alternatively, could the dispatcher check to see if the python side 
> exists and, if not, call super's implementation?  Likely, no -- that 
> is probably a bad idea.

>
> Assigning self->isa to self->isa->superclass is problematic, as well.
Why would 'self->isa = self->isa->superclass' be problematic? This 
would be a hackish way to achieve the previous item. There actually is 
a precedent for this: This is basically what happens during the 
destruction of C++ objects (if I recall this correctly, I haven't done 
C++ programming for some time).

>
> --
>
> This sounds like you are fighting a battle that may not need to be 
> fought.   If I understand correctly, this will only occur if the 
> Python part of the object is destroyed before the ObjC side and, 
> hence, the walk up the -release tree can cause problems?   
> Specifically, the problem occurs when the metainformation used to glue 
> the ObjC and Python objects together is released before the ObjC side 
> is done with it?

It specifically happens while deallocating the Python/Objective-C 
hybrid. As it is impossible to deallocate both at the same time, we'll 
have to do it in some order. The current implementation first 
deallocates the Python half and then the Objective-C half (most 
specific part first). That this happens during a call to release rather 
than dealloc is a result of the implementation. Details escape me at 
the moment, but is has something to do with getting the reference 
counts right. Hmm, I see some documentation coming...

How would you do this in Objective-C? Do you call [super dealloc] at 
the start of the end of -dealloc, or maybe in the middle? I suppose you 
have to call it at the end. But what if [super dealloc] calls a method 
that has been overridden and uses some already cleaned-up resources?

Ronald