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

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

[cc'ing Guido because this is all part of the reasoning behind an 
earlier 2.3 'change request' asking if it would be possible to add 
weakref support to <string> and <unicode>]

On Friday, Feb 7, 2003, at 14:25 US/Eastern, Ronald Oussoren wrote:
> Preserving identity both might be hard to do without introducing 
> garbage (in the memory management sense). This may not be relevant for 
> strings, but I ran into this when thinking about a solution for the 
> problems we're having with using Python objects as the model for an 
> NSOutlineView. Preferably you'd keep the OC_PythonObject proxy alive 
> as long as the Python object. Obviously the Python object must be 
> alive as long as the OC_PythonObject proxy is. If you combine the two 
> you get immortal objects :-(

If weakrefs were supported by <unicode> and <string>, that could 
help... or do we only get the callback-upon-finalize when it is too 
late to "save" the object from destruction?   I don't think it would 
matter [taking advantage of the immutability of Python strings and the 
general lack of importance of the identity of a string on the python 
side].

- on ObjC side, everything revolves around retain/release.   If retain 
count drops to zero and the object is deallocated [there are hooks to 
catch this at a low level -- don't know about viability, should look in 
source], then the ObjC side can be deallocated because there is 
[should!] no longer be a viable reference to the string from the ObjC 
side.   If the string is subsequently 'rebridged', it doesn't matter.

- on Python side, if the reference count drops to zero, the same thing 
can happen.  We just need a hook to remove the association between the 
Python <string>/<unicode> and the NSString instance in the bridge.

Another way to phrase this:   Like we can transition an object from 
being present in one runtime to being present in both runtimes, we need 
a way to undo that association.  Once the reference count for an object 
drops to zero on either side of the bridge, the bridging for that 
object can be removed -- the object returns to only be accessible on 
one side of the bridge.

Clearly, the transition from bridged to unbridged may not always be so 
straightforward.  If either side is using the internal backing store of 
the other side, the act of 'unbridging' where the backing store is 
about to be destroyed will have to cause the backing store to either be 
moved or duplicated to the other side of the bridge.

For the [very broken, but a potentially right direction] implementation 
of OC_PythonString, having it transition from using the PyString 
backing store to an entire copy contained within an NSString or 
CFString would be trivial *assuming we can receive notification that 
the PyString object is about to be deallocated and before its backing 
store has been invalidated*.   When this happens, the PyString 
reference could be nullified-- indicating that the OC_PythonString now 
lives entirely on the ObjC side of world.  Rebridging is simply a 
matter of creating a new PyString/PyUnicode reference and passing it 
off to Python.

Going the other way *sounds* like it would be more feasible with 
unicode objects than it would with string objects in that unicode 
objects have their backing store as a slot whereas strings are 
all-in-one.   When the OC_PythonString is -dealloc'd, it could copy its 
contents into freshly malloc'd backing store for the PyUnicode object...

NSString -> Python bridging is slightly more difficult in that the 
OC_PythonString like functionality cannot be implemented as a subclass 
of NSString.    It could be implemented as a subclass of unicode, I 
suppose?   Also, we would have to verify that the...

/usr/include/objc/objc-runtime.h:OBJC_EXPORT id (*_dealloc)(id);

... hook works as expected (and pay the price for being the ones to 
override it -- we are hosed if someone else overrides it).  The 
alternative is to override/swizzle NSObject's -dealloc method to do 
what we need.  That doesn't excite me much either.

Too bad ObjC doesn't have some kind of a weakref-with-notifier 
concept....

b.bum