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

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

On Thursday, Oct 17, 2002, at 22:42 Europe/Amsterdam, Bill Bumgarner 
wrote:

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

Automaticly conversion in one direction is not very pretty. I prefer to 
add automatic conversion from NSNumber to a Python type (but I'll have 
to check if this is possible without loss of information).

>
> >>> 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
This is a bug. a[0] implements isEqual:, this means we should 
automaticly add '__eq__' to the python proxy.
>
> 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.
This might already be a problem for strings. There is quite a large 
number of string constants in Cocoa, and I don't know if the identity 
('pointer value') of them is significant.

> 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??
These should be added, maybe including '__int__' for transparent 
conversion to a Python integer if the object is passed to an extension 
module.
>
> 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.
I agree.

> It can also lead to some serious inefficiency if a trip across the 
> bridge implies a copy each time.
With small values the copy is not that inefficient (the overhead of the 
interpreter is probably much more significant)

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

I definitly do not want to get rid automaticly adding methods, but it 
might be possible to replace the current implementation with a more 
flexible solution.

As I mentioned before I do not want to add more automatic conversions 
because:
1. The identity of objects may be significant
2. Conversion might be inefficient (especially for collections)
3. The Objective-C objects often have a larger interface than their 
Python counterparts, automatic conversion would make it impossible to 
use the additional functionality.

Ronald