Ahh, I have been trying for over a year to realize the implications and
requirements for doing this.  I have arrived at the conclusion, with much
help from many people - basically the entire squeak community, that we need
a specialized object reference that allows us to manage, and 'bend' the
message send.  I am still not satisfied with a Proxy, subclassing from nil
or ProtoObject or Object.  there is the identity problem and there is some
protocol that isn't fowarded to the real target.
 
Is it correct that you view Components as my 'UserSpace', so to speak?   It
is the component that loads Modules, generates VariableBindings and
initializers scoped to the component boundaries.   The external references
(which was the topic of discussion when these threads made to this list) are
really of two types.  One type is an external variable binding, that is
looked up by global named reference resolution (compiler
#pushResolvableLiteral).  The other type is an external object reference.
Of course, the external object reference could point to a Class...
 
Could you briefly tell us how Firewall specified external object references?
Were they just the proxy pattern or was there special VM support for them?
There is the identity issue and message sending and lookup issues.  These
external object references could also be of many types like:  external
component/environment, remote, persistent, unloaded.
 
thank you,
- Rob
 
 -----Original Message-----
From: Allen Wirfs-Brock [mailto:Allen_Wirfs-Brock at Instantiations.com]
Sent: Tuesday, August 21, 2001 2:49 AM
To: Withers, Robert; 'squeak-dev at lists.squeakfoundation.org'
Cc: modsqueak at bluefish.se
Subject: RE: [Modules] Components or Modules??



I think you're pushing into an important space with this message.

I'm not yet ready to talk about name spaces in the context of modules (I
think there are more basic things that still need to be air first) but I
think your questions about the execution environment are very important.

As I view the virtual machine it's simply an execution engine for message
semantics. The important fundamental things it supports are instantiation,
object references, object identity testing, and message sending. A single,
shared class library  isn't  a key element of the virtual machine. From this
perspective there are lots of interesting things you can do.  For example,
you can have separate independent class libraries co-resident in the same
image. (There are some minor issues relating to nil and the booleans and a
few other things, but those are all solvable). The can use conflicting
names, the virtual machine doesn't care. They can even have conflicting
class definition, and the virtual machine still doesn't care.  However,
objects defined by independent class libraries can still reference each
other and exchange message.

If starting from scratch, my first cut at "components" would be to define a
component as a namespace containing a self contained class hierarchy defined
from a set of modules.  Multple such components could be in a single image
and the could communicate via object references and messaging.  I would not
permit inheritance relationships  or name sharing among between such
components.  There are, however, various sharing  "optimizations" that could
be applied by the implementation when multiple components incorporate the
same modules. 

Starting from that you could easily imagine a "tool space" that was
independent from the "user space".  In fact, you could have multiple "user
space".

We used a trick like this in our Firewall systems to allow a user to see a
very simple class library that didn't include all the implementation classes
(CompiledMethods, Metaclasses, contexts, etc.) needed by the virtual
machine. All we had to do was treat the implementation classes as an
independent hierarchy that wasn't in the namespace of the user's programs.
Similary, we put all the classes necessary to support remote control and
debugging of the image into another separate hierarchy/namespace. The
functionality was all there in the image but the user constructing an
application didn't need to see it or worry about conflicting with it.


At 02:30 PM 8/20/2001 -0400, Withers, Robert wrote:



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
<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/20010821/e9056ab1/attachment.htm