...snip...

Lex,

I snipped your great response, for this post, so that we could break it
up into a series of different discussions.

First, some background on SmallScript:

a) It has mixins
b) It has interfaces
c) You can instantiate interfaces
d) Interfaces can have concrete fields

Now, some comments on the summary section you wrote:

<quote>
Okay.  After this whirlwind tour, here's a summary on the question that
spurred it off:

	classes: behavior, structure, namespace, maybe types, interfaces
(though normally not in the program code)

	modules: ownership, namespace

Are these really the same type of thing?  They only overlap at
namespaces.
</quote>

My descriptions would include:

Class-Entity:
    - metadata repository for "class-as-an-entity" properties
      - version services
      - module entity services
        - owning module
      - namespace entity services
        - external module repository (database)
	    - DLL entry points [pragmatics require: resources, etc]
        - imported & inherited namespaces
        - language-namespace of selectors (Symbols)
        - language-namespace of (typed) shared-fields (pool-entries)
        - language-namespace of (typed) enum-consts
      - extensible collection of typed metadata properties
        - schema migration services
        - via basic object model services for metadata properties
          on any (non-virtual) object

    - constructor for "class-object"
	- behavior of class-object
        - includes associated external module entry points
        - interfaces & mixins (include/exclude set)
        - instance constructor methods and other class functions
      - structure of class-object
	  - parameterized/typed field defs (incl/initializer spec)
        - object memory defaults and policies
      - metadata repository for class-object properties
        - vtable mappings, super-behavior, super-types, 
          constructor-group, strong-name, ...

    - constructor for "instance-objects"
	- behavior of instance-objects 
        - includes pure-functions and associated external 
	    module entry points 
        - interfaces & mixins (include/exclude set)
      - structure of instance-objects
	  - parameterized/typed field defs (incl/initializer spec)
        - object memory defaults and policies
      - metadata repository for shared instance-object properties
        - vtable mappings, super-behavior, super-types, 
          constructor-group, strong-name, ...

Module-Entity:
    - metadata repository for "module-as-an-entity" properties    
      - version services
	- module entity services
	  - ownership [owned module-entity elements]
        - persistence/lifecycle [relates to external module repository]

          - image-slice/versions via [module repository]
	- namespace entity services (i.e., may, or may not, 
        also be used as a language-namespace)
        - external module repository (database(s))
	    - DLL entry points, resources, etc
        - imported & inherited namespaces
        - language-namespace of selectors (Symbols)
        - language-namespace of (typed) shared-fields (pool-entries)
        - language-namespace of (typed) enum-consts
      - extensible collection of typed metadata properties
        - schema migration services
        - via basic object model services for metadata properties
          on any (non-virtual) object

    - constructor for "module-object"
	- behavior of module-object (may, or may not, have unique
behavior)
        - includes associated external module entry points
        - interfaces & mixins (include/exclude set)
        - instance constructor methods and other class functions
        - module lifecycle behavior and custom services
      - structure of class-object
	  - parameterized/typed field defs (incl/initializer spec)
        - object memory defaults and policies
      - metadata repository for class-object properties  
        - vtable mappings, super-behavior, super-types, 
          constructor-group, strong-name, ...

    - constructor for "instance-objects"
      - not currently used, but may serve for supporting a
        complex repository (via a singleton), or for supporting
        multiple repositories or multiple repository versions.
        For source code management of modularized code/images,
        there are already half a dozen or more different types 
        of repositories (required for host integration).

* 
  The above descriptions are not meant to be exhaustive, but 
  merely illustrative. Not all capabilities are used in all
  scenarios. I apologize, but I need to stop here because
  I've got to run and do some other things... 
*

-- Dave S. [SmallScript Corp]

SmallScript for the AOS & .NET Platforms
David.Simmons at SmallScript.com | http://www.smallscript.org