Re: [Pyobjc-dev] In and out of NSData

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

On Wednesday, Jan 8, 2003, at 11:45 Europe/Amsterdam, Jack Jansen wrote:

>
> On Wednesday, Jan 8, 2003, at 07:24 Europe/Amsterdam, Ronald Oussoren 
> wrote:
>> Proposed interface:
>>
>> 	Foundation.pyobjc_NSToCF(NSObject) -> CFObject
>> 	Foundation.pyobjc_CFToNS(CFObject) -> NSObject
>>
>> Both raise ValueError if the argument cannot be mapped to the other 
>> representation.
>>
>> These are uncontroversion, except maybe the location of the 
>> functions. When I first looked at doing this I intended to implement 
>> pyobjc_CFToNS as part of the generic bridge; that is, if the 
>> Objective-C code expects to receive an NSObject and the user passed 
>> in a CFObject automaticly translate between the two. I'm currently 
>> not sure whether that would be a good idea, stuffing a CFObject in a 
>> NS<Datastructure> and retrieving it again would effectivly change its 
>> type. This might be pretty confusing (especially because the 
>> translation from NSObject to CFObject won't be automatic).
>>
>> I'm therefore inclined to making all mappings from CF to NS and back 
>> manual operations.
>
> Let's start with this, and we can always do more later.
>
> But: why would going CF->NS->CF change the type of the object?
It wouldn't, but given the automatic translation from CF to NS (NOT 
using the pyobjc_CFtoNS function) the following code would have 
unexpected results:

	input = CF.CFMutableData(...)
	arr = Foundation.NSMutableArray.arrayWithArray([data])
	output = arr[0]

At this point 'output is not input', the do not even have the same 
type(). Converting it back to CF would of course recover an object of 
the same type as 'input'.

That's why I'd prefer to only implement the pyobjc_CFtoNS and 
pyobjc_NStoCF functions and not transparent translation.

Ronald