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

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

On Friday, Feb 7, 2003, at 20:48 Europe/Amsterdam, Just van Rossum 
wrote:
>
>> Those can already be accessed
>> using unbound methods (NSString.fooMethod(strVal)).
>
> But this doesn't work for mutable strings...

Not currently, but we'd stuff a reference to the NSString in an unicode 
object we could get this to work. But using your sugestion of 
explicitly dropping the python object and using the Objective-C object 
directly is probably better.

>
>> 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.
>
> Yeah, I don't care about this either until it's _proven_ to be a
> bottleneck. "Premature optimization is the root of" etc.

I couldn't agree more.

>
>> * NSMutableString should be visible in Python as a mutable object
>>    No objections here, some APIs won't work until we fix this.
>
> As far as I'm concerned this is the only _real_ requirement.
>
>> * 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.
>
> I'm not sure I'm following you. When going from ObjC -> Python -> ObjC,
> the Python representation of the string can safely hold a strong
> reference to the NSString. _This_ is the case where Bill claims object
> id is relevant. I still don't believe him, but it doesn't matter,
> because as soon as we keep the original NSString around this 
> requirement
> is automatically met.

What I meant is that if you get hold of the same ObjC object through 
two different method calls the proxies will have the same object id. We 
currently don't use this mechanism for strings. If object identity 
really is important in Cocoa that should be changed.

That only covers ObjC -> Python, going back to ObjC requires more work.

>
> Going the other way, Python -> ObjC -> Python, there is _no_ 
> requirement
> to keep the object id the same. So we can just _convert_ to NSString 
> and
> forget about the original. So this will be an autoreleased object. Of
> course this gives problems when the receiver doesn't retain it yet does
> store a reference, but we have that problem anyway, and is easy to work
> around.
And the sad thing is that it easy to keep the object id the same when 
going Python -> ObjC -> Python. OC_Python{Object,Array,Dictionary} 
already do it for 'plain' objects, lists and dicts. Adding a proper 
OC_PythonString (subclassing from NSString) would be easy.
>
>> 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 vey much doubt this is possible (and if it is it will be a very
> complex and hairy implementation), hence my suggestion to simply punt 
> at
> this issue. The PyObjC idiom for dealing with mutable strings would be
> this:
>
>    s = someCallThatIsKnownToReturnAMutableString()
>    # Toss the Python string, because it won't be sync'd with
>    # the NSString, and is also if limited use to Python code
>    # as using it as a dict key will not work as expected
>    s = s.nsstring
According to our coding style this should be 's = s.pyobjc_nsstring', 
but otherwise I agree.

>
>> I have serious doubts on the feasability(sp?) of this, but I
>> wouldn't mind if someone surprised me by providing a working
>> implementation ;-) ;-)
>
> Let's keep it simple, and live with the simple wart-by-design that the
> Python representation will _not_ be kept the same as the underlying
> NSMutableString.
>
That's fine with me.

Ronald