Re: [Pyobjc-dev] pickled Objective-C objects

[Just v. R. <ju...@le...>]

bb...@ma... wrote:

> On Monday, Feb 24, 2003, at 13:29 US/Eastern, Just van Rossum wrote:
> > Is objc._convenience the right place for this? I guess not since it
> > currently doesn't even import Foundation.
> 
> Maybe, maybe not.   Likely, the correct approach would be to test the
> object to see if it responds to the NSCoding protocol.  If it does,
> then NSArchiver/NSUnarchiver can be used to archive/unarchive
> instances of the class and, hence, the class is pickle compatible.

Well, I assume if you try the NSConding protocol on an object that
doesn't support it, an exception is raised. This would be entirely
correct behavior and I don't see why we would have to check in the first
place.

> > PS: It seems NSData doesn't support the buffer protocol; you can't
> > pass a string where an NSData is expected, and
> > str(anNSDataInstance) doesn't do the right thing.
> 
> Can the buffer protocol be implemented entirely on the Python side of 
> the bridge?   Is so, it should be easy to support?

Not sure.

> If not, then the ObjC->Python proxy would have to be extended to offer 
> buffer protocol features *only* if appropriate. 

Meaning? When would it not be appropriate? Are there situations where
str(anNSDataInstance) would not be meaningful? Same for the reverse;
it's just annoying to have to do

    NSUnarchiver.unarchiveObjectWithData_(
            NSData.dataWithBytes_length_(data, len(data)))

instead of simply

    NSUnarchiver.unarchiveObjectWithData_(data)

> Given the way this is 
> implemented, I believe the implication is that we would need to 
> effectively create a second proxy class [python C-API type class] that 
> contains non-NULL entries for the buffer protocol support?

I'm not following, but then again, I'm not familiar with the
implementation.

Just