Re: [Pyobjc-dev] Bridging NSMutableString, a compromise

[Just v. R. <ju...@le...>]

Ronald Oussoren wrote:

> On Friday, Feb 7, 2003, at 22:31 Europe/Amsterdam, Just van Rossum 
> wrote:
> > Btw. I noticed PyObjC tries to sync the refcounts for both objects
> > in class-builder.m's object_method_retain() and
> > object_method_release() calls. Why is this needed?
> 
> This is for Python subclasses of Objective-C classes (and only those). 
> Such instances have two parts, an Objective-C object and a Python 
> object, that behave as if there is 1 object. Using 1 refcount for both 
> parts is IMHO the only feaseable way to ensure that we don't end up 
> with only one of the parts and that these objects are not immortal.
> 
> Getting this right was one of the hardest elements of my rewrite of 
> PyObjC, and something that really should be documented...

For lack of documentation <wink>, I hope you don't mind me asking the
following, because I must be missing something deep:

Why are there _two_ relevant objects instead of just one being the
"master"? Without looking at the code I would have assumed it would work
like this:
a) a native ObjC object
b) a thin Python wrapper, only containing a ref to the ObjC objects

The ObjC object could have a __dict__ ivar that can store arbitrary
attributes. The wrapper can be reconstructed from the native object at
any time, and the native object may live longer than the wrapper if the
ObjC runtime retains it. Apart from this not guaranteeing object
identity on the Python side, as well as having to recreate the wrapper
when the object enters Python again, I don't see any immediate flaw. An
optimization would be to store a weakref to the wrapper in the native
object to avoid reconstruction of the wrapper. But it's just that: an
optimization.

Just