Anthony Hannan <ajh18 at cornell.edu> writes:
> Data (message arguments and results) are trees of data records, aka,
> objects but without predefined behavior.  Receiving components define
> their own behavior for each type (class) of record.  

Hi Anthony,

I like it. Please excuse some naive questions.

I'm having trouble getting my head around the nature of component
boundaries. Could you say a little more about the above ?  Can I pass
an object in to a component, and have the component then invoke the
objects' methods ?  Perhaps a simple example ?

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

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 ?

Regards,
-Simon