Re: [Pyobjc-dev] Re: [Pyobjc-checkins] CVS: pyobjc/Modules/objc class-builder.m,1.7,1.8 pyobjc.h,1.8,1.9

[<bb...@ma...>]

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?

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.

--

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?

If that is the case, structure the -release something like:

-(void) release
{
     ... release ivar stuff here ...
     [super release];
     ... release meta information here ...
}

Pure conjecture-- you know about 2 orders of magnitude more about this 
piece of the bridge than I.

b.bum