I've followed this thread with great interest, and believe that managing filed in code is key to allowing Smalltalk's popularity and utility to increase.  I am a newbie who is simply impressed by squeak, so please excuse me if I am extremely naive about the complexities of managing filed in code within Smalltalk.
 
Swan, Dean" Dean_Swan at Mitel.COM wrote:
>If anything I was trying to make the point that flexibility does
>not come for free, and that I prefer Dan Ingalls's original premise of
>"the simplest thing that could possibly work".
 
I agree with keeping it simple, and that probably means some simple changes to the base classes rather than some terribly complex change management application.
 
As I see it, Smalltalk is analogous to an extensible operating system, and until filed in classes have attributes that set them apart from the base release classes, there will exist this messy problem of installing and uninstalling what are essentially applications.
 
If every class had class variables that identified it as a base-release or application class, an application name, and an index number assigned at file in time, wouldn't that make the whole thing dead simple to manage?
 
You could then easily remove any particular application's classes, you could even install the same application several times.
 
If any application relied on classes of another filed in application, the user could be asked to choose the name and install index of the prerequisite classes from a list of previously installed applications at file-in time.  And this would only really be necessary in cases where multiple applications had the same class names.
 
The biggest break with Smalltalk as it is today would occur when the same app, or similar apps exist within the same image.  Then the user would have to choose which 'instance' of the application classes should be launched.
 
Or is the problem much more complex than this?