Hi everyone,

I am really, really enjoying these discussions of Modulization of Squeak.
It may take awhile, but the enrgy gathering in support of this is amazing.
It seems complex to me because of being a complex topic crossing the core
language areas of the meta level and with the execution environment.  There
are two areas, in particular, that I am really unclear about (only two!?!?
ha!).  

First off, where does the concept of Namespaces fit into Modules versus
Components?  This is clearly a meta-level modularization, separating class
definitions and extensions into different semantic spaces.  Is this
orthogonal to Modules and Components?

The second question is what aspect of Modularity partitions the execution
environment of Squeak into separate spaces?  I don't even have a good name
for it, since it isn't a Component, although a Component may represent a
separate execution environment.   It isn't a Module, since a Module is a
chunk of definitional space.  If we view a Module a declarative, then there
is definitely no execution space in it, neither active nor inactive.  It is
only when we attempt to install a Module that we would build execution
context.

The concept of a user space is a good description, to me, of a partitioned
chunk of execution space.  Does this synergize with anyone else?  If we take
this perspective of gaining access to an image, the contents of this user
execution context depends on how you initialize and utilize this "execution
space".  With the concept of a user execution context, we would have a
multi-user system, each with disjoint resources and definitions
"installed"and bound into their user-context.  I apologize for mixing the
terms state, context, and execution-space, but I mean the same thing with
them; they may be synonymous.

Thus our lowest layer of orthogonal cuts would be:
1a) execution environment:    User spaces, each with a unique global
environment.  Shared Globals?
1b) process environment:     Processes, executing within a User Space.
Shared Processes?
2)  Namespaces:   separation of definitional elements between semantic
spaces

followed by:

3)  Modules:      development spaces, that allow independent control of
chunks of code
4)  Components:   deployment mechanism

regards,
Rob

> -----Original Message-----
> From: Allen Wirfs-Brock [mailto:Allen_Wirfs-Brock at Instantiations.com]
> Sent: Thursday, August 16, 2001 5:13 PM
> To: squeak-dev at lists.squeakfoundation.org
> Cc: modsqueak at bluefish.se
> Subject: [Modules] Components or Modules??
> 
> 
> So what are we trying to accomplish?  Dan listed a set of 
> "desiderata" that 
> I can whole-heartedly support.  However, I would like to step 
> up one level 
> before plunging into the details.
> 
> My understanding is that a common goal is the elimination of the all 
> encompassing, monolithic image. I can't argue with that goal 
> and I don't 
> think I need to reiterate all reasons this is desirable.  
> However, there 
> are a lot of different  reasons that different constituencies 
> have for 
> wanting to see this happen.  I don't necessarily believe that 
> one solution 
> will make everybody happy.  I also think this may be one 
> reason that there 
> appears to be a lack of consensus on an approach to 
> modularity.  Different 
> people are trying to solve different problems.
> 
> If one tool won't do the job then the next simplest  thing is to have 
> exactly two tools that collective will.  For conquering the 
> monolithic 
> image, I'm going to argue that the two tools we need are 
> "components" and 
> "modules".   Clearly, I need to define what I mean by this 
> terms.  I'll 
> start by trying to list some distinguishing characteristics:
> 
> Function		Components			Modules
> --------------------------------------------------------------
> ----------------------------
> Organizes		behavior			
> definition of behavior
> When			runtime				development time
> composition		dynamic			static
> coupling		loose				tight
> via			object refs/messages		
> inheritance/naming/syntax, etc.
> 
> Roughly speaking Components correspond to COM or CORBA 
> objects, DLLs, SLLs 
> in Visual Smalltalk, etc.
> 
> Roughly speaking Modules correspond to Java source files, 
> Envy projects, 
> TEAM/V packages, Smalltalk change sets.
> 
> Modules are all about organizing and managing code, 
> Components are all 
> about composing functionality (behavior).  Modules are used to create 
> components.
> 
> Most module systems end up have some (usually weak) component-like 
> characteristics. Most component systems have some (usually weak) 
> module-like characteristics. To me, all of the various 
> systems I've heard 
> described in this discussion appear to fit primarily in one 
> or the other of 
> these categories with some features that are more appropriate to the 
> other.  (Here is my first crack assignment based upon limited 
> visibility.  Component systems: Environments, OASIS, (I don't 
> really know 
> enough about either but this is my impression) , Pope's 
> selector ideas. 
> Module systems: Pelrine's work, change sets). My impression 
> is that people 
> who are primarily thinking about component issues have 
> problems with module 
> systems because they don't see what they are looking for visa 
> versa. Most 
> of my work with modularizing Smalltalk has been on the module 
> side.  However, I think there is a real place for the 
> component view. Many 
> of the rough edge I encountered in module systems have been 
> in areas where 
> they have tried to support component like usage.
> 
> So here's my strawman position: Squeaks needs both a module 
> architecture 
> and a component architecture. They should be designed to be 
> complementary 
> to each other. The module system should stick to development time 
> issues.  The component system should stick to runtime issues. 
> Globally, 
> some people should be thinking about how to slice the image 
> into components 
> and modules.
> 
> Allen
> 
> 
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20010820/ea1c26ae/attachment.htm