Re: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

[Bill B. <bb...@co...>]

On Thursday, October 17, 2002, at 04:18 PM, Ronald Oussoren wrote:
> On Thursday, Oct 17, 2002, at 20:29 Europe/Amsterdam, Bill Bumgarner 
> wrote:
>> On Thursday, October 17, 2002, at 02:01 PM, Bob Ippolito wrote:
>>> IMHO there should also be easy to use wrappers for NSNumber and 
>>> NSData.. I use those on a pretty regular basis for stuff that needs 
>>> to get serialized for DO or plists.
> I'd prefer not to special case Objective-C classes in the extension 
> module. We currently do so for NSString and NSNumber, and I'd prefer 
> to not add other exceptions.

NSNumber is definitely bridged from Python -> ObjC, but not the other 
way around (this is what caused me to say that NSNumber wasn't bridged)?

 >>> x = NSArray.arrayWithObject_(1)
 >>> x[0]
<NSCFNumber objective-c instance 0xc1d0e0>
 >>> x.objectAtIndex_(0)
<NSCFNumber objective-c instance 0xc1d0e0>

I'm not implying that I think the above behavior is incorrect -- I'm 
not really sure if I think it is or not.... In the following, it would 
seem that bridging would be the right thing to do:

 >>> a = NSMutableArray.array()
 >>> a.addObject_(1)
 >>> a.addObject_(1)
 >>> a[0]
<NSCFNumber objective-c instance 0xca1510>
 >>> a[1]
<NSCFNumber objective-c instance 0xc905b0>
 >>> a[0] == a[1]
0
 >>> a[0].isEqual_(a[1])
1

But not always -- if the developer were to ever run into a case where 
the (id) of a[0] and a[1] are significant, the transparent bridging of 
the NSNumber->Python(int/float/long) would force the developer to go to 
ObjC for something that is likely trivial to implement.

I remember running into this issue in the Java Bridge (and in the 
Tcl<->ObjC bridge I wrote in 1990/1991/1992).

With all that said, I don't see any reason why NSNumber should not 
provide implementations for at least __eq__ and __ne__ -- and maybe 
even the full set??

__lt__(a, b)
__le__(a, b)
__eq__(a, b)
__ne__(a, b)
__ge__(a, b)
__gt__(a, b)

In any case, bridging types where the type is copied should generally 
be avoided.  It can make it impossible to deal with certain situations 
where the address of the object is meaningful, but the contents are 
not.  It can also lead to some serious inefficiency if a trip across 
the bridge implies a copy each time.

.... response continued below ....

> The current mechanism is a bit of a hack: the 'objc' module maintains 
> a list of methods that are added if a selector is present in the 
> objective-C class (e.g. if the class has 'objectForKey:' add an 
> __getitem__ method that calls objectForKey_). This should work for 
> most collection classes.

This is actually a really good solution in that it greatly automates 
the bridging process and should work transparently with the 'no cost' 
bridged CFTypes.

Anything that makes a copy of data as it is passed across the bridge 
should generally be avoided -- strings are about the only exception.

Unlike the Java bridge, we have the distinct advantage of working with 
two relatively light weight, highly dynamic, languages on either side.  
Java really wants to be a closed box -- it really wants to tightly 
control everything passed into it and, as such, the bridge often had to 
copy and recreated data as it passed across (i.e. there was no way to 
wrap an NSMutableArray instance such that it was a subclass of Vector 
in any kind of an effective fashion).

Python's embedding API provides for a heck of a lot more informal 
flexibility...

b.bum