[Pharo-project] Fuel - class loading issue when superclass changed inst vars

Henrik Johansen henrik.s.johansen at veloxit.no
Tue Mar 6 06:05:27 EST 2012

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.


More information about the Pharo-dev mailing list