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

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

On Friday, Feb 7, 2003, at 19:23 Europe/Amsterdam, bb...@ma... wrote:

> On Friday, Feb 7, 2003, at 13:07 US/Eastern, Ronald Oussoren wrote:
>
>>> The only mutable strings that we want to represent as Pythonic string
>>> lookalikes are those returned in places where the promise was that 
>>> we would get an
>>> NSString.
>> The only way to detect that the API promises to return an (immutable) 
>> NSString is by parsing header files, as far as the Objective-C 
>> runtime (and therefore PyObjC) is concerned all classes are the same 
>> when mentioned in method signatures.
>
> This won't work for methods that are not advertised in public API 
> (but, of course, the developer is on their own at that point anyway) 
> and will require third party developers to parse their headers before 
> using PyObjC with their frameworks/code.
>
> It would also stick a serious wrench in the whole 'development 
> environment on machine without dev tools installed' concept.

I probably should have added some smileys here, I definitely didn't 
want to imply that we should parse header files.

>
>>> I think it's a safe assumption that the code returning 
>>> NSMutableString in
>>> stead of NSString will at least have the common decency not to 
>>> modify the contents
>>> behind our back.
>> I sure hope so ;-)
>>
>> Another BTW: We currently try to convert the NSString to ASCII before 
>> building a unicode object when going from Objective-C to Python, if 
>> performance is an issue we should at least do away with that piece of 
>> code and just always convert NSString objects to unicode.
>
> If we preserve identity then, in theory, this issue would be greatly 
> reduced in that the conversion would only happen the first time the 
> object crosses the bridge?

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 :-(

Ronald