Hi Tim and Daniel, thanks for your responses.  Daniel, your the first
one to agree with me. Yeah!

Daniel Joyce <daniel.a.joyce at worldnet.att.net> wrote:
> Take a look at Traits before reinventing the wheel. I think Traits are 
> the best tradeoff between MI and SI w/o all the ugliness.

I think stateless multiple inheritance and Traits are very similar.  But
there are two things I don't like about Traits from what I read at
http://www.iam.unibe.ch/~schaerli/research/publications/ECOOP2002Traits.
pdf.
	1. Traits cannot inherit from each other.  If I want to create a new
trait, say TTranslucentColor, that is similar to another trait, say
TColor, I can't inherit methods from it.  I either have to copy the
methods or keep the traits distinct and make user classes use both and
glue them together.
	2. Traits introduces another type of behavior object.  So now you have
classes and traits to deal with, which adds complexity.

I think my version of multiple inheritance does handle the "ugliness" of
it without adding complexity.
	1. Classes no longer have instance variables, only primitive accessor
methods.  This eliminates inheritance of state and inst var index
confusion.  Primitive accessor methods raise an error if applied to
subclasses, so subclasses have to implement their own accessor methods. 
These can automatically be copied from superclasses if desired.
	2. Selectors are typed, binding them to a class.  If a class wants to
be polymorphic with another class it has to inherit from it and override
desired selectors.  This is not as restrictive as it seems since a
subset of polymorphic selectors can alway be extracted out into a new
abstract superclass and inherit from it.  This actually promotes good
factoring.  Since selector are no longer just names, random selector
name clashing won't happen.  A clash will happen only if more than one
independently inherited class override the same inherited selector, in
which case a true ambiguity exists and error is raised on method lookup.

> [Enviornments] sounds like PIE, I posted a message with exactly these
> ideas a few weeks ago.

The only thing I found was a message from you on Nov 5 stating:
"I plan on laying out my ideas on PIE/Versioning/Traits tonight and 
submitting a URL to it all...
I KNOW a hybrid of ideas found in Traits and PIE can be used to solve 
versioning, and other issues..."
But I do not see the follow up the next day.

> Also, it gives us other goodies too, like easy type-inferencing.

Yes, typed selectors facilitates this.

> > The key to this design, and any package design, I think, is that
> > class extensions are first class objects (I make them new super
> > behaviors). When they are not first class objects they act like
> > changes to a class. Changes is a lot harder to manage and mix than
> > separate objects, so you want to keep them to a minimum.  In this
> > design, only true behavior changes need to be managed as changes. 
> > They are managed as versions in environments that override versions
> > in inherited environments.
> >
> 	Bingo! 
> 	We're saying the same thing here guys...

Tim Rowledge <tim at sumeru.stanford.edu> wrote:
> I have to agree. Classes provide structure and behaviour for a single
> kind of thing (how quickly we run out of words when 'class' and 'type'
> are already taken). A package is a bunch of stuff that may touch many
> classes in many ways. Not the same.

I have already conceded this.  See my last message.  In my proposal,
environments are now analogous to packages.

> And anyone that starts going on about multiple inheritance is looking for
> a visit from one of the four horsement of the apologists. :-)

I think this is a myth of multiple inheritance.  I think it can be tamed
and used effectively.  See above.

Finally, with respect to PIE, I think my environments proposal captures
the essence of PIE.  In fact, PIE was my inspiration, along with
PerspectiveS and Us (Subjective Self).

Cheers,
Anthony