I appreciate the need for initialization.  Let's make it simpler
than Java/ANSI Smalltalk by requiring a module to be a persistent
immutable object.  We should not care how an object came to be in 
a particular state, only that we can make a mutable copy of that
state.

When you look at it this way, initialization code is just one way to
create a copy of a particular object state and should not be fundamental
to our definition of modules.

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org
> [mailto:squeak-dev-admin at lists.squeakfoundation.org]On Behalf Of Allen
> Wirfs-Brock
> Sent: Monday, August 20, 2001 11:05 PM
> To: squeak-dev at lists.squeakfoundation.org
> Cc: modsqueak at bluefish.se
> Subject: Re: [modules] {Image Shrink and Initialization}
> 
> 
> Dave's experience with initialization pretty much matches mine although I 
> have tended to prefer the constructive approach.
> 
> I think part of the problem people have had adapting to additive modules is 
> that many existing classes libraries haven't been designed with 
> initialization or re-initialization in mind. In many cases Classes (or 
> probably more importantly mutually dependent sets of classes) that needed 
> complex initialization have often been initialized with ad hoc doIts that 
> aren't captured as reusable code.  Even, if the initialization code is 
> placed in a change set or file-in as a do-it it tends to get forgotten 
> because it doesn't show in the browser when looking at the class.
> 
> I think to make additive modules work reliably and repeatedly you need the 
> following support for initialization:
> 
> 1) Initialization code needs to be treated as first class code entities by 
> the language and tools. Team/V did this and this is the reason that the 
> ANSI Smalltalk language definition includes class and global variable 
> initializers as language elements.
> 
[remainder snipped]