Andreas Raab wrote:
> Stephen,
> 
> 
> I have the impression that a majority of
> people on this list believes that modules will solve "all the problems
> of Squeak". This is wrong on many (if not all) accounts.

Yipes! I agree, and I didn't mean to imply anything negative about 
SqueakC. No aspersion casting was intended. As I said, I think it will 
be *a little bit* less a question of discussion, and *a little bit* more 
a question of scratching an itch. It's a matter of degree. I said 
"trampled upon" just to make the metaphor work -- it was the wrong 
choice of words.

 > Modules will not solve the problem of integration

True, but they will make it *a little bit* easier. If SqueakC decides to 
change a module on which my work depends, it won't effect my work *until 
I want it too*. I can still use the old version of the effected module 
with my project. And I can still use the newer version of that same 
module in applications that require the newer version. All of that is 
possible without modules, but it will be a bit easier to do with them.

 > Modules will not solve the problem of what is in
 > the "base image" and how to find things that are not in.

True, but that is not what makes it daunting to write an alternative 
widget set. What difference does it make if you have a great system for 
finding alternatives to what is in the base image if those alternatives 
doen't exist in the first place?

 > Modules will not solve the problem of what
 > "the default experience" should be.

One of SqueakC's missions, according to the SWIKI, is to experiment with 
UIs. The default experience is very important, and it is fun and 
interesting to discuss. But making it easier to have alternate 
experiences will help the default experience in the end. I hope, in the 
partitioning of the image into modules, that part of the intent is to 
create a Morphic kernel that implicitly encourages alternatives to the 
look and feel of the SqueakC version. If not, then what is the deeper 
motivation for modules in the first place?

 > just don't expect unreasonable results from that work.

Noted.