Re: [Pyobjc-dev] In and out of NSData
Brought to you by:
ronaldoussoren
From: Jack J. <Jac...@cw...> - 2003-01-08 10:44:52
|
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? If that is an artefact of the fact that the various Carbon.CF types don't currently inherit from each other: don't worry, this will be fixed shortly (all the other Carbon types now do have inheritance, for CF it was slightly difficult because I already used "poor mans inheritance" to get access to (for instance) the CFType methods from CFString objects, etc. -- Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman |