Re: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa
Brought to you by:
ronaldoussoren
From: Bill B. <bb...@co...> - 2002-10-17 20:42:46
|
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 |