<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META content="MSHTML 5.00.2920.0" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=974023418-21082001>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.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=974023418-21082001></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=974023418-21082001>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...</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=974023418-21082001></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=974023418-21082001>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.</SPAN></FONT></DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN
class=974023418-21082001></SPAN></FONT></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=974023418-21082001>thank
you,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=974023418-21082001>-
Rob</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=974023418-21082001></SPAN></FONT> </DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN
class=974023418-21082001> </SPAN>-----Original Message-----<BR><B>From:</B>
Allen Wirfs-Brock [mailto:Allen_Wirfs-Brock@Instantiations.com]<BR><B>Sent:</B>
Tuesday, August 21, 2001 2:49 AM<BR><B>To:</B> Withers, Robert;
'squeak-dev@lists.squeakfoundation.org'<BR><B>Cc:</B>
modsqueak@bluefish.se<BR><B>Subject:</B> RE: [Modules] Components or
Modules??<BR><BR></DIV></FONT>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px"></FONT>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 class=cite cite type="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></BLOCKQUOTE></BODY></HTML>