Simon Michael <simon at joyful.com> wrote:
> I'm having trouble getting my head around the nature of component
> boundaries.  Can I pass an object in to a component, and have the 
> component then invoke the objects' methods ?

Yes, but only if the object itself is a component, otherwise, it will
look up its own methods for that class of object.  Components
communicate with other components by doing real message sends, but
communicate with regular objects by looking up messages in it own
environment.

> Would your packages typically, mostly be class & method
> (re)definitions?  And would your components mostly be a
> namespace/environment + one or more instantiated objects ?

Yes, a component is an object whose class has its own environment that
inherits/overrides immutable packages.  That environment takes over for
the process's method and global lookup until another component is
called.

> The packages and components you describe remind me of classes and
> objects writ large, with versioning and immutability (and smart
> distributed demand loading & syncing) added. It seems like you could
> in principle implement these semantics down at the class and object
> level? But the larger groupings (package and component) are useful for
> manageability and distributed performance ?  Or am I way off track
> here ?

You're right, every object could be a component.  This would bring us
back to normal Smalltalk, where every object's class dictates its own
behavior.  But since classes can change in different images I wanted a
way to make sure that objects brought in from other images follow the
local class behavior, which is what I programmed for.  That is why I say
only data is brought into a component.  The ambiguity about which class
to use for an imported object is now explicitly resolved by making the
imported object either a component or just a regular (data) object.

I could have just specified classes as exported or not, but usually many
classes go together along with extra methods for other classes.  So I
think the proper unit of export is the component.  Also, components take
over the role of what traditionally was the image.  Now you can have
many self-contained components (mini-images) running on the same virtual
machine, sharing the same objects.

The distributed loading and syncing is rather orthogonal to components
(but is what caused me to think of components in the first place).  Any
object (a component or not) could by migrated by reference, copy, or
replica.  A replica is a copy that is kept in sync with its original. 
When a component wants to execute a method on an object reference, it
can either replicate itself or the object.  In my previous email I
described replicating the component.

Even though components are independent, there should be some common
packages that they share, especially with regards to objects (data) that
pass between them.  And keeping packages immutable allows us to
replicate them across images without worrying about keeping them in
synch.

Security is an issue that I have been putting off, but a security
mechanism would restrict distribution of certain objects and prevent
unauthorized components from executing methods that access private data.

Simon, thank you very much for your response.  It gave me another chance
to clarify my ideas which I know I need.

Regards,
Anthony