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

[Just v. R. <ju...@le...>]

Ronald Oussoren wrote:

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

But why bother?

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

Why the prefix? It's not a global name, it's a new attribute to an
object with not all that many methods and attributes, so clashes aren't
likely. It offers access to the underlying NSString, so .nsstring seems
very intuitive to me.

Just