[Biococoa-dev] Comments on BCAnnotation

[Charles PARNOT]

>>* In the comparison: more generally, if the Contents are of the same class and both respond to 'compare:', then this is what is used
>What do you try to say? I don't get the point..

Sorry it was very very brief... Here is what I mean.
In the headerdoc of 'compareContents:' you say it does use compare: when the class of the contents is NSString or NSNumber. More generally, it could use 'compare:' if the instance in Contents responds to it. That would be more general. The user could put objects of her own that responds to 'compare:' and would be sorted gracefully even if not NSString or NSNumber. In other words, the headerdoc could explain that and the implementation could use 'respondsToSelector:@selector(compare:)' to check the behavior of the contents object.


>>* the data type should be an ivar, if you want to preserve annotations coming from another app; in which case the contents is NSData; more precisely, when unarchiving, if the class is known, the contents is unarchived; otherwise, the ivar 'contentsClass' stores the class name and the ivar 'contents' stores the unarchived data;
>Again, I'm not really what you would like to see.

I was just trying to anticipate what is going to happen when you unarchive the feature:
* first you unarchive 'contentsClass' = NSString *theClass
* then you check that NSClassFromString(theClass) != nil
* if it is not nil, then fine you can unarchive the contents object and you call 'decodeObjectForKey:'
* if it is nil, then what do you do?? The object is lost and you can't reencode it later
I could not find a solution to that issue.

 OK, then, the archiving should archive this:
* the class type as NSString
* the 'contents' object wrapped in NSData using 'archivedDataWithRootObject:'
* the 'name' as NSString

Now, when unarchiving:
* you unarchive the name
* you unarchive 'contentsClass' = NSString *theClass
* then you check that NSClassFromString(theClass) != nil
* if it is not nil, then fine you can unarchive the NSData object calling '-decodeObjectForKey:' and then unwrap the contents using '+unarchiveObjectWithData:' (this could be simplify if the class is part of the Cocoa framework, which we could test for; also it assumes that if the root object class exists, then the children object classes also exist)
* if it is nil, then you simply store the NSData object for future archiving
* but for future archiving, you also need to store the contentsClass, otherwise you have know way to remember what it is when archiving --> hence the need for an ivar 'contentsClass'

I hope this was clearer, and maybe I am missing a more elegant solution.

charles



-- 
Help science go fast forward:
http://cmgm.stanford.edu/~cparnot/xgrid-stanford/

Charles Parnot
charles.parnot at stanford.edu

Room  B157 in Beckman Center
279, Campus Drive
Stanford University
Stanford, CA 94305 (USA)

Tel +1 650 725 7754
Fax +1 650 725 8021