Eric Scharff wrote:
[plea of innocence expurgated]
 > a pool dictionary, a concept I never mastered and haven't done so bad in
 > avoiding.  I think the lookup works like this and in roughly this order.

Pool Dictionaries are basically pools of variables that a given class can 
subscribe to.  The wonky thing about Pool dictionaries is that there are 
actually two different roles filled by the same class- the other role is to hold 
the "class variables" ( not a class's instance variables ).  Those are 
anonymous, basically- only the class knows about it, and the Pool does not have 
a so-called "definition" class.  Throughout all of Squeak, you will only find a 
handful of non-anonymous Pools, ones which do have a definition class.  The 
definition class for a given pool takes care of the creation and initialization 
of that pool, a task which the programmer must explicitly describe.  Why bring 
this up?  Because the non-anonymous pools *are* special- and I think that they 
need to be handled differently than what has been done in the past.  They need 
to be able to stand on their own, not needing another object ( such as some 
randomly chosen class ) that operates on it.  The pool should aquire some 
behavior-like quality, a self-like ability to define it's own initialization on 
a per-instance basis, alongside a shared batch of behavior that it shares with 
all other Shared Pools.

This becomes *very* important in a system where you can, or have, broken the 
image up into individual modules.

[ more stuff ]
 > * How will modules change how changesets work?

Changesets already work with modules, just in the singular sense.

 > * Will we have multiple update streams for the different modules? (This
 > seems natural and might allow multiple owners to maintain their own
 > module specific update streams, which may be good or bad)

I think it is going to be pretty much neccessary- how else is a community based 
system going to work?  Each module ( in Allen's terms ) will have its own 
community, and its own life.  This is a fundamental property that has to be 
considered.

 > * Can we somehow combine modules, update streams, and projects?  (This
 > seems especially beneficial because change sets and projects are already
 > connected.)  This would also be part of a somewhat grandiose vision I have
 > about how to deal with documentation in Squeak.  I think that projects are
 > a fantastic way to document how a module works.  They can be interactive,
 > are easily sharable and changeable, and many different projects can explore
 > different parts of the system.  I can write more if folks are interested.

Hang onto that thought as we go- this is a rather important issue.  Might also 
check this out:

	http://sabine.canis.uiuc.edu:8080/Squeak/The+Visible+Squeak

 > ====
 >
 > I decided to stop rambling now and try to ask the question, "How will
 > modules impact how us unenlightened users use the system."  Specifically
 >
 > 1) How will language semantics (scope and inheritance) be affected?
 > 2) Will modules be bound at compile time (file-in time) or execution-time?

The user should not be put in a position where they are thinking of these 
things.  It should be transparent, aside from a curiousity to see what is going 
on, which most people ( rightly so ) will not do.  They should just be able to 
use it, without having to think about how things are working.

 > 3) What is the impact of modules on tools (browsers) and other existing
 > module-like schemes, like change sets, Projects, and update streams?

I'm going to pass on talking about that for now... my experience has been that 
operationally, things probably will appear very similar to their pre-module 
incarnation.  But significant and difficult changes may be neccessary under the 
covers.

 > Finally, I'd like to thank the folks that are taking up the difficult
 > challenge of addressing this.  Like others, I think that modules are
 > definitely a Good Thing and can benefit the Open Source process, managing
 > complexity, learning the system, supporting collaborative development, and
 > many more.  I look forward to hearing more about this!

Thanks- I am very optimistic about this round of the battle... the issues are 
finally being understood by enough people, that I think we have a pretty good 
chance to make some significant progress this time.

- les