<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: [Modules] Components or Modules??</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>Hi everyone,</FONT>
</P>
<P><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!). </FONT></P>
<P><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?</FONT></P>
<P><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.</FONT></P>
<P><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.</FONT></P>
<P><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>
</P>
<P><FONT SIZE=2>followed by:</FONT>
</P>
<P><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>
</P>
<P><FONT SIZE=2>regards,</FONT>
<BR><FONT SIZE=2>Rob</FONT>
</P>
<P><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>
</P>
</BODY>
</HTML>