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

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

On Friday, Feb 7, 2003, at 22:59 Europe/Amsterdam, Just van Rossum 
wrote:

> 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

That might also work. I wanted NSObject to behave as much as possible 
like a 'proper' new-style class (including __slots__), without copying 
code from the python implementation. It might be worthwhile to 
reexamine this issue after we get strings working properly.

Ronald