On Mar 6, 2012, at 12:03 PM, Henrik Johansen wrote: >> > > Parcels > - Check a hash based on class layout vs equivalent hash for the stored > method's class (stored with the method). > If different: > 1) check for existence of a backwards-compatability reader method, hand the > old instance to it, and expect the old instance to be #become'd into > something current, > 2) raise an error if no such method exists. > > Now, the main problem with this scheme is it's left as an exercise to the > user to come up with a procedure to ensure said backwards-compat reader > method stays up to date as additional changes are made. > > Is it a big problem? > Depends on your tests, and programmer diligence at any given day. > > Added inst vars are not a big deal, as if you forget them, there will usually > be a nil #DNU somewhere down the line. (or you use lazy initialization, and > everything works as expected even for existing instances) > > Removals/reorderings are a bigger issue, as the detection of failure (inst > vars in wrong slots) are often far removed from the source of problems > (forgetting to update the reader method), > If seldomly used, it may even go unnoticed until the instance is next saved, > at which time you're in real trouble (especially if saved alongside newly > created ones, in which case there is no consistency). > > In general I think it's an ok scheme, but would like to see a solution more > resilient to user-error. > How to achieve that is an interesting topic, which I haven't yet found time > to think through as thoroughly as I had wished/intended some months ago. :(
Errr, BOSS, not Parcels. My bad. Cheers, Henry
