> I'll give you an example. Currently SystemWindow has several ivars that are
> associated with the window label and control boxes, such as label, closeBox,
> collapseBox etc. Each of those morphs are stored in the SystemWindow
> submorphs list, with a 'cached' handle in the ivar. That's fine, but what
> happens when you try to change the structure of a SystemWindow instance? (In
> my case, I would like to remove all of the instance variables related to the
> window frame, this would work smashingly well for new instances of
> SystemWindow, but the existing instances would be *very* disappointed with
> my change and would probably tell me about it with cute little pink
> dialogs).

You say "structure" as if it were a bad thing!  It seems better to
decide how dynamic each property should be, instead of making every
property completely dynamic.  Is it really so wonderful to have four
SystemWindow instances on the screen, each with different instance
variables?  Perhaps in some cases, but probably not for all or even most
instance variables.  Consider: the more optional variables there are,
the less informative the class of the object is.  The more optional
variables there are, the more if-then's there will be in the code.

To contrast, the transition problem can always be solved.  At worst, you
can write an "update" method that gets called at the end of your
changeset.  At best, you can update all accesses to the new variable so
that they can cope with an old instance  (probably by calling the same
"update" method as above, really!).



-Lex