Re: [Pyobjc-dev] Auto bridging instances by conversion

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

bb...@ma... wrote:

> If the goal is to make the bridge as transparent as possible,
> automatically converting instances-- and losing the original
> instance-- as they pass across the bridge should be eliminated.

If this is a refcount problem I can see that, but other than that, since
Python numbers and NSNumber instances are immutable I don't see why it
would ever matter to get a different instance. Wg. in Python it is an
implementation detail that ints between -1 and 99 (as well as the empty
tuple, empty string, strings of length 1) are singletons: one should
never rely on that.

To me, making "the bridge as transparent as possible" means the exact
opposite: native Python objects on the Python side (strings, ints,
floats, etc) and using native Cocoa objects on the ObjC side. I don't
care about the performance hit, and I'm not even sure passing numbers
back and forth over the bridge is such a common thing (but I'm sure you
can prove otherwise ;-).

> The fact that NSString<->PyString are converted is a bug --

To me it isn't, it's what I call "transparent". This feature is
absolutely a _pleasure_ to work with.

> certainly, a bug we have chosen to live with until a better solution
> comes along. Mostly, we can get away with this because two strings
> with the same contents act like the same string.

Yeah, that's a neat property of them being immutable. I would figure the
same goes for NSNumber, so apart from performance I don't see anything
against converting back and forth.

> For Python strings -> Objective-C, it is simply a matter of creating
> a subclass of the NSString class cluster in the same fashion as we do
> for NSArray and NSDictionary.    For NSString -> Python StringType,
> it isn't clear that there is a set of methods or a base type to
> inherit from that can make an NSString behave like a python string
> transparently enough to make it a worthwhile pursuit at this point in
> time.

It is clear: there is no such base class. In 2.3 there is an abstract
base class called basestring but that doesn't implement anything.

Just