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@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org]On Behalf Of Allen Wirfs-Brock Sent: Monday, August 20, 2001 11:05 PM To: squeak-dev@lists.squeakfoundation.org Cc: modsqueak@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:
- 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]