Fwd: [stdev] Fwd: Special case of class migration

Norbert,

Forwarding James' answer ... plus some commentary from Martin McClure:

  I agree with James' analysis. In talking with him,
  we came up with a briefer way to describe the basic
  concept. In this case, Norbert wants to keep both instvars
  in his existing instances, so James suggested "don't create
  a new subclass, create a new superclass". The general
  principle is "The class to create is the class that won't
  get the existing instances."

Dale
----- Forwarded Message -----
| From: "James Foster" <[hidden email]>
| To: "Dale Henrichs" <[hidden email]>
| Cc: "Smalltalk Developers" <[hidden email]>
| Sent: Wednesday, October 10, 2012 11:36:02 AM
| Subject: Re: [stdev] Fwd:  Special case of class migration
|
| My proposed answer:
|
| The tweak of adding the child as a new version of the parent is
| necessary (and reasonable) to allow the migration. To restore
| "correctness" one could save copies of the classHistory for both
| classes before the migration and then restore them afterwards.
|
| An alternate that might be slightly "cleaner" would be create a "new"
| superclass (BaseClass) rather than a new subclass (DerivedClass).
| This could be done with the following steps:
|
| (1) Replace BaseClass with DerivedClass using one of the following
| three approaches:
| (1a) Create DerivedClass with the same schema as BaseClass
| (including the same superclass) using "normal" subclass creation,
| add DerivedClass as a version of BaseClass, migrate instances, and
| remove BaseClass from the SymbolList;
| (1b) Create DerivedClass with the same schema as BaseClass
| (including the same superclass) using the the subclass creation
| method that includes 'newVersionOf:' in the selector (this takes
| care of the classHistory), then continue as (1a) with migrate
| instances and removing BaseClass;
| (1c) Rename and move BaseClass to DerivedClass (using "private"
| methods that work just fine; no migration required, and
| classHistory does not change):
| | myClass |
| myClass := UserGlobals removeKey: #'BaseClass'.
| myClass _beVariantWhile: [myClass name: #'DerivedClass'].
| UserGlobals at: myClass name put: myClass.
| This might leave tools confused; they should be fine if you close and
| reopen the browser.
|
| (2) Create a new BaseClass with instVar 'one'.
|
| (3) Create a new version of DerivedClass, this time without instVar
| 'one' and with BaseClass as the superclass.
|
| (4) Migrate instances from the old DerivedClass to the new
| DerivedClass.
|
| These ideas are from memory. I've not actually done them just now
| (though I recall doing them in the past) and there might be details
| I've missed.
|
| James
|
| On Oct 10, 2012, at 10:54 AM, Dale Henrichs wrote:
|
| >
| >
| > ----- Forwarded Message -----
| > | From: "Norbert Hartl" <[hidden email]>
| > | To: "GemStone Seaside beta discussion"
| > | <[hidden email]>
| > | Sent: Wednesday, October 10, 2012 6:22:05 AM
| > | Subject: [GS/SS Beta] Special case of class migration
| > |
| > | I have a class BaseClass that has two instVars 'one' and 'two'.
| > | Now I
| > | need to make a derived class DerivedClass from BaseClass.
| > | BaseClass
| > | has the instance variable 'one' and DerivedClass has instance
| > | variable 'two'. I'm looking for a migration scheme that works on
| > | that case.
| > | I have it working by
| > |
| > | - switching off auto migration
| > | - creating the sub class DerivedClass
| > | - moving instance variable 'two' from BaseClass to DerivedClass
| > | - doing: BaseClass addNewVersion: DerivedClass
| > | - doing: BaseClass migrateInstancesTo: DerivedClass
| > |
| > | But I'm not sure if the tweak by adding the DerivedClass to
| > | BaseClass's history causes any trouble/side effects. Or is this
| > | to
| > | be done in a different way?
| > |
| > | thanks,
| > |
| > | Norbert
| > _______________________________________________
| > stdev mailing list
| > [hidden email]
| > https://lists.gemstone.com/mailman/listinfo/stdev
|
|