<html>
I think you're pushing into an important space with this
message.<br><br>
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.<br><br>
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.<br><br>
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. <br><br>
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".<br><br>
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.<br><br>
<br>
At 02:30 PM 8/20/2001 -0400, Withers, Robert wrote:<br><br>
<blockquote type=cite class=cite cite><font size=2>Hi everyone,</font>
<br><br>
<font size=2>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!). <br>
</font><br>
<font size=2>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?<br>
</font><br>
<font size=2>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.<br>
</font><br>
<font size=2>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.<br>
</font><br>
<font size=2>Thus our lowest layer of orthogonal cuts would be:</font> <br>
<font size=2>1a) execution environment: User spaces, each with a unique global environment. Shared Globals?</font> <br>
<font size=2>1b) process environment: Processes, executing within a User Space. Shared Processes?</font> <br>
<font size=2>2) Namespaces: separation of definitional elements between semantic spaces</font> <br><br>
<font size=2>followed by:</font> <br><br>
<font size=2>3) Modules: development spaces, that allow independent control of chunks of code</font> <br>
<font size=2>4) Components: deployment mechanism</font> <br><br>
<font size=2>regards,</font> <br>
<font size=2>Rob</font> <br><br>
<font size=2>> -----Original Message-----</font> <br>
<font size=2>> From: Allen Wirfs-Brock [<a href="mailto:Allen_Wirfs-Brock@Instantiations.com">mailto:Allen_Wirfs-Brock@Instantiations.com</a>]</font> <br>
<font size=2>> Sent: Thursday, August 16, 2001 5:13 PM</font> <br>
<font size=2>> To: squeak-dev@lists.squeakfoundation.org</font> <br>
<font size=2>> Cc: modsqueak@bluefish.se</font> <br>
<font size=2>> Subject: [Modules] Components or Modules??</font> <br>
<font size=2>> </font><br>
<font size=2>> </font><br>
<font size=2>> So what are we trying to accomplish? Dan listed a set of </font><br>
<font size=2>> "desiderata" that </font><br>
<font size=2>> I can whole-heartedly support. However, I would like to step </font><br>
<font size=2>> up one level </font><br>
<font size=2>> before plunging into the details.</font> <br>
<font size=2>> </font><br>
<font size=2>> My understanding is that a common goal is the elimination of the all </font><br>
<font size=2>> encompassing, monolithic image. I can't argue with that goal </font><br>
<font size=2>> and I don't </font><br>
<font size=2>> think I need to reiterate all reasons this is desirable. </font><br>
<font size=2>> However, there </font><br>
<font size=2>> are a lot of different reasons that different constituencies </font><br>
<font size=2>> have for </font><br>
<font size=2>> wanting to see this happen. I don't necessarily believe that </font><br>
<font size=2>> one solution </font><br>
<font size=2>> will make everybody happy. I also think this may be one </font><br>
<font size=2>> reason that there </font><br>
<font size=2>> appears to be a lack of consensus on an approach to </font><br>
<font size=2>> modularity. Different </font><br>
<font size=2>> people are trying to solve different problems.</font> <br>
<font size=2>> </font><br>
<font size=2>> If one tool won't do the job then the next simplest thing is to have </font><br>
<font size=2>> exactly two tools that collective will. For conquering the </font><br>
<font size=2>> monolithic </font><br>
<font size=2>> image, I'm going to argue that the two tools we need are </font><br>
<font size=2>> "components" and </font><br>
<font size=2>> "modules". Clearly, I need to define what I mean by this </font><br>
<font size=2>> terms. I'll </font><br>
<font size=2>> start by trying to list some distinguishing characteristics:</font> <br>
<font size=2>> </font><br>
<font size=2>> Function Components Modules</font> <br>
<font size=2>> --------------------------------------------------------------</font> <br>
<font size=2>> ----------------------------</font> <br>
<font size=2>> Organizes behavior </font><br>
<font size=2>> definition of behavior</font> <br>
<font size=2>> When runtime development time</font> <br>
<font size=2>> composition dynamic static</font> <br>
<font size=2>> coupling loose tight</font> <br>
<font size=2>> via object refs/messages </font><br>
<font size=2>> inheritance/naming/syntax, etc.</font> <br>
<font size=2>> </font><br>
<font size=2>> Roughly speaking Components correspond to COM or CORBA </font><br>
<font size=2>> objects, DLLs, SLLs </font><br>
<font size=2>> in Visual Smalltalk, etc.</font> <br>
<font size=2>> </font><br>
<font size=2>> Roughly speaking Modules correspond to Java source files, </font><br>
<font size=2>> Envy projects, </font><br>
<font size=2>> TEAM/V packages, Smalltalk change sets.</font> <br>
<font size=2>> </font><br>
<font size=2>> Modules are all about organizing and managing code, </font><br>
<font size=2>> Components are all </font><br>
<font size=2>> about composing functionality (behavior). Modules are used to create </font><br>
<font size=2>> components.</font> <br>
<font size=2>> </font><br>
<font size=2>> Most module systems end up have some (usually weak) component-like </font><br>
<font size=2>> characteristics. Most component systems have some (usually weak) </font><br>
<font size=2>> module-like characteristics. To me, all of the various </font><br>
<font size=2>> systems I've heard </font><br>
<font size=2>> described in this discussion appear to fit primarily in one </font><br>
<font size=2>> or the other of </font><br>
<font size=2>> these categories with some features that are more appropriate to the </font><br>
<font size=2>> other. (Here is my first crack assignment based upon limited </font><br>
<font size=2>> visibility. Component systems: Environments, OASIS, (I don't </font><br>
<font size=2>> really know </font><br>
<font size=2>> enough about either but this is my impression) , Pope's </font><br>
<font size=2>> selector ideas. </font><br>
<font size=2>> Module systems: Pelrine's work, change sets). My impression </font><br>
<font size=2>> is that people </font><br>
<font size=2>> who are primarily thinking about component issues have </font><br>
<font size=2>> problems with module </font><br>
<font size=2>> systems because they don't see what they are looking for visa </font><br>
<font size=2>> versa. Most </font><br>
<font size=2>> of my work with modularizing Smalltalk has been on the module </font><br>
<font size=2>> side. However, I think there is a real place for the </font><br>
<font size=2>> component view. Many </font><br>
<font size=2>> of the rough edge I encountered in module systems have been </font><br>
<font size=2>> in areas where </font><br>
<font size=2>> they have tried to support component like usage.</font> <br>
<font size=2>> </font><br>
<font size=2>> So here's my strawman position: Squeaks needs both a module </font><br>
<font size=2>> architecture </font><br>
<font size=2>> and a component architecture. They should be designed to be </font><br>
<font size=2>> complementary </font><br>
<font size=2>> to each other. The module system should stick to development time </font><br>
<font size=2>> issues. The component system should stick to runtime issues. </font><br>
<font size=2>> Globally, </font><br>
<font size=2>> some people should be thinking about how to slice the image </font><br>
<font size=2>> into components </font><br>
<font size=2>> and modules.</font> <br>
<font size=2>> </font><br>
<font size=2>> Allen</font> <br>
<font size=2>> </font><br>
<font size=2>> </font><br>
<font size=2>> </font><br>
<font size=2>> </font><br>
<font size=2>> </font></blockquote></html>