On 17 Feb 2013, at 11:33, Fred Kiefer wrote:
Now that I am almost through with the changes to CGFloat, NSInteger and
NSUInteger in gui I realized that I did not think about coding. When the
size of an instance variable changes from int to NSInteger what should
happen to the coding/decoding code? Lets take the tag of an NSControl as
the example. The old -initWithCoder: code may look something like this:
[aDecoder decodeValueOfObjCType: @encode(int) at: &_tag];
Now _tag no longer is an int, is now is an NSInteger. Will that code still
work?
Should we change it to @encode(NSInteger)? (I think that is was base did)
But that will be something different depending on the machine the code
runs on? Is the coding mechanism able to handle that? And will this work
for CGFloat as well? And what about old archives, e.g. Gorm files?
For the last batches of changes I no longer changed the types of the
instance variables. That is a valid workaround, but only delays the
decision what to do. Using local variables of the old type for
coding/decoding would also work, but again looks wrong to me.
NSArchive/NSUnarchiver is supposed to cope with size differences between
architectures automatically, but I'm not sure it will cope with different
types without objecting (though I guess, if it doesn't, we could make it do
so).
That is, if we encode a 32bit int on one machine, it's ok to decode it as a
64bit int, and if we encode a 64bit int, we can decode it as a 32bit int (as
long as the original value can fit in a 32bit variable).