Re: [Pyobjc-dev] NSString & mutability

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

I've implemented a scheme that was mentioned on the list a while back 
during the discusion of posing and which should make experimenting with 
the various proposed solutions a little easier (mostly for the creation 
of a Python representation of Objective-C instances, wrapping Python 
strings using a custom proxy object seems to be rather 
uncontroversial). Not only that, it also makes the bridge code slightly 
simpler.

What I've done:

* All custom proxy-objects (OC_PythonObject and friends) implement 
__pyobjc_PythonObject__. This
   method returns a new reference to the wrapped Python object
* All Python subclasses of Objective-C classes also implement this 
method
* And last but not least, a category on NSObject also defines this 
method (both as an instance and
   as a class method). Both return a proxy for self (the instance of the 
class).

pythonify_c_value, case _C_ID, is now a lot simpler than it was before: 
It calls __pyobjc_PythonObject__. End of story.

This works rather well, and it is quite easy to add support for special 
treatment for some classes, I've done so for NSString and NSNumber: 
Just implement a category implementing __pyobjc_PythonObject__
and your done.

The __pyobjc_PythonObject__ implementation for NSNumber converts back 
to the corresponding Python number, which solves the bug in 
test_nsundomanager (the int->NSNumber problem mentioned by David). The 
functions in Foundation.Conversions don't like this change (obviously). 
test_nsnumber also fails, because NSNumber instances are no longer 
visible from Python.

The __pyobjc_PythonObject__ implementation for NSString exactly mirrors 
the code that is currently in pythonify_c_value. Feel free to 
experiment with that code :-)

BTW. Is anyone using the Objective-C style interface to Python objects 
as defined by OC_PythonObject (e.g. [pyobject1 numberAdd:pyobject2])? 
I'd like to remove this interface as most interesting types are, or 
will be, proxied using classes with a Cocoa-style interface anyway.

I'll check these changes in later on this evening (it is evening over 
here in Europe :-), after cleaning up some issues with other pending 
changes.

Ronald