Re: NSKeyedArchiver and Forwards Compatibility Strategies
Re: NSKeyedArchiver and Forwards Compatibility Strategies
- Subject: Re: NSKeyedArchiver and Forwards Compatibility Strategies
- From: Graham Cox <email@hidden>
- Date: Sun, 20 Apr 2008 14:29:37 +1000
I have run into the same issues - in my case I can always convert a
subclass back to a superclass that is usable, but I don't see a
problem with your keyed archiver delegate returning an NSNull object
for classes it doesn't know about, or even just nil. You'll need to
experiment to see if NSArray will ignore nil when unarchiving without
raising an exception - if so you're in business. If not, you can
substitute NSNull objects which it will accept, and either weed them
out later or leave them in in which case they'll just sit there doing
nothing. The latter case might throw off your object counts though (if
it matters), so ideally you probably want to get rid of them. But at
least NSNull objects are easy to identify whereas substituting a
legitimate class makes those objects impossible to tell apart from
other instances of the same class that are "real".
hth,
G.
On 20 Apr 2008, at 5:21 am, Colin Cornaby wrote:
I have an array of objects. The objects are all subclasses of one
parent class. (For the sake of this email, I will say that the
subclasses are all different kinds of graphics that can be
displayed, and the superclass defines generalities that all graphics
have in common.)
My concern here is that I may add new kinds of graphics in later
versions of my software. I would like earlier versions of my
software to read files from the later versions of my software, but
obviously the earlier versions won't be able to work with data
structures that they have no concept of.
Currently, I am thinking that I should probably set up the delegate
of my NSKeyedUnarchiver to handle unknown classes, substitute in the
superclass, and then afterwords remove any instances of the
superclass from the array. (The issue here is that the superclass
cannot actually be displayed by my software. While it defines
general graphics attributes, it doesn't define include any code
necessary to actually parse the graphical data attached to my class,
and therefore probably should be ignored by my software.)
Is this the best way to deal with this situation? Will I receive
notifications when the NSArray, which is a node of the root of the
archive, fails to unarchive one of it's objects? Is there a way I
can simply tell that NSArray not to unarchive that object as part of
it's dataset, instead of cleaning up afterwards?
Thanks,
Colin
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden