Re: [Pyobjc-dev] Re: [ pyobjc-Bugs-679748 ] NSMutableString gets converted to Python string

[Bob I. <bo...@re...>]

On Monday, Feb 3, 2003, at 17:42 America/New_York, Bill Bumgarner wrote:

> On Monday, Feb 3, 2003, at 17:36 US/Eastern, Just van Rossum wrote:
>> This seems the worst of both worlds, performance wise: allocate new
>> storage *and* keep the old object? Hm...
>
> If implemented correctly, the allocation only happens once the first 
> time the object crosses the bridge from ObjC->Python.   From then on, 
> the bridge should be able to use the already existing instance of 
> NSString when going from Python->ObjC.   The challenge will be when 
> going from ObjC->Python after the first invocation.  I'm hoping the 
> weak reference code that is already present in the bridge will provide 
> some kind of a solution.
>
> The truth will be revealed in the code, I suppose.

Is it really the worst of both worlds, performance wise?  If you have 
*both* available, you have a native object to work with on both sides 
of the bridge.  Since you're keeping the NSString around, when/if it 
needs to get passed back you don't need anything special on the ObjC 
end.  It also has the potential to save a lot of programmer hours (for 
everyone using pyobjc), I think, which is more important for Python 
users IMHO.

It might use twice the memory, but how often do you pass gigantic 
NSStrings around over a bridge?  If you really wanted to garbage 
collect the NSString (assuming it has no references on the ObjC side) 
you could do myUnicodeNSStringWrapper = 
unicode(myUnicodeNSStringWrapper) or myNSStringWrapper = 
str(myNSStringWrapper).

In any case, as far as I can tell, you still need to have both 
allocated at the same time at one point *if* you want something that 
can act like a PyString or PyUnicode without the pyobjc user knowing 
too much about it.  You might as well keep both around as long as you 
need them.

-bob