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

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

On Friday, Feb 7, 2003, at 17:38 Europe/Amsterdam, Jack Jansen wrote:

>
> On Friday, Feb 7, 2003, at 11:14 Europe/Amsterdam, Just van Rossum 
> wrote:
>
>> I've been doing some thinking, and now have some doubts that "fixing"
>> Python to allow mutable dict keys will solve everything. Biggest
>> problem: if we wrap an NSMutableString in a (mutable) unicode 
>> subclass,
>> how are we going to keep the two strings synchronized?
>>
>> Here's an idea for a compromise that might work and yet be convenient 
>> to
>> work with from Python in the majority of cases.
>>
>> Problem:
>>
>> - We need NSStrings to work like Python strings as _much_ as possible.
>>
>> - We need access to the methods of the NSString, or to put it in other
>> words, we need to have full access to the native object, _especially_ 
>> if
>> it's mutable.
>
> I've been thinking about it long and hard, but I don't see why the 
> second assertion
> is true. And my feeling is that all the complexity comes from that 
> assertion.

Given the size of the NSString API I'd assume that at least one method 
is usefull for Python programmers :-). Those can already be accessed 
using unbound methods (NSString.fooMethod(strVal)).

The current problems seem to result from the following assertions:
* Copying strings is too expensive
   I'd like to see some figures here, creating proxy objects also has a 
cost and depending on the
   size of strings creating a proxy might not be signifantly faster than 
building a 'foreign'
   string object.
* NSMutableString should be visible in Python as a mutable object
   No objections here, some APIs won't work until we fix this.
* The identity (id()) of strings is significant
   I have no idea whether this is true or not. Note that it would be 
easy to make sure that when
   an instance of NSString is passed to Python through two paths the two 
"proxies" have the same
   identity. This is already true ordinary objects and only requires 
that strings/unicode objects
   can have weakrefs.

BTW. This whole discussion reminds me of a simular discussion related 
to NSArray/NSDictionary and
list/tuple/dict. At the time is was suggested to create subclasses of 
list/dict to represent
NSArray/NSDictionary. This seemed like a good idea (code testing for 
isinstance(foobar, list) would
accept NSArray instances) we soon discovered that the implementation of 
Python assumes it can poke
in the actual datastructure, which of course wouldn't be very helpfull.

The best idea I've seen so far for the path from Objective-C to Python 
is subclassing str or unicode. I think this would work fine for 
immutable strings, but doing this for mutable strings might be 
problematic, unless we can somehow arrange that the internal 
representation of the NSMutableString and our unicode subclass are the 
same. I have serious doubts on the feasability(sp?) of this, but I 
wouldn't mind if someone surprised me by providing a working 
implementation ;-) ;-)

> 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.

> 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.

Ronald, on the other end of a 10-foot stick ;-)