Stephane Ducasse <ducasse at iam.unibe.ch> wrote:
> > Layers (environments as I have described them on my website) are
> > dynamically bound namespaces and nothing more.  This allows you
> > to override them to change the behavior in different layers.  Thus
> > giving you multiple packages/projects that can be run and analyzed in
> > the same image.  Being able to work on different packages/projects in
> > the same image is important, and without something like layers it can't
> > be achieved.
> 
> so you have a different method lookup that is layer aware?

Yes. (In the following discussion "environments" and "layers" are
synonymous)

Every process runs with respect to an environment.

Globals, class pointers, and superclass pointers are environment
selectors instead of direct pointers.  When encountered they are looked
up in the current process's environment (and inherited environments),
returning the behavior/object from that environment's point of view.  So
method lookup goes as follows:  lookup receiver class in environment,
lookup method in resulting class, if not found lookup superclass in
environment, lookup method in resulting class, and so on.

Environement entities (classes and globals) are the units of versioning.
 I.e. if an environment wants to change just a single method it
conceptually creates a brand new version of the entire behavior.  But we
can optimize this so behavior versions are diffs chained together
creating their own hierarchy to be traversed.

But since the VM only executes one process at a time we can flatten the
environment hierarchy into a global dictionary and have global
variables, class pointers, and superclass pointers point to its
associations.  This way we can use the normal method lookup algorithm. 
Upon environment change the new environment would be flattened into the
global dictionary overriding the old environment, also the method cache
would be flushed or saved/restored.

> > That's what also bothers me about traits.  I wish you would just use
> > straight multiple inheritance and eliminate the extra concept of traits
> > when there really isn't an extra concept.  Layers is different.  Its an
> > extra concept that adds another dimension of functionality, which is
> > needed in a multi view/version world.
> 
> Traits add a extra smaller abstraction for reuse.

"Smaller" is not worthy of a separate concept if its in the same
"dimension"; just have smaller behaviors.  Traits and behaviors are the
same concept/dimension: groups of methods that can inherit from each
other.  They are not two different concepts, so I wouldn't implement
or present them as such.

Cheers,
Anthony