Classes as Packages (was: Harvesting infrastructure)

Nathanael Schärli n.schaerli at gmx.net
Mon Nov 18 20:01:41 UTC 2002


Hi Anthony, hi all

I think that one of the main problem here is that Anthony refers to a
workshop paper about Traits that is not up-to-date anymore. Furthermore,
the paper had to be written an only about 2 days in order to make the
submission deadline. As a consequence, the paper is not quite precise in
describing the limitations and problems with mixins and MI, and in
addition, the Trait model has evolved a lot since then.

In particular, a Trait is now able to access overridden or conflicting
methods implemented in the Subtraits it is composed from. This means
that Trait composition is powerful enough to create a Trait
TTranslucentColor by using a Trait TColor. No copying of methods will
ever be necessary!

We are just about to write a paper about the latest version of Traits
and to submit it to the ECOOP conference. We are not quite finished, but
I made the latest draft available on my web-page:

http://www.iam.unibe.ch/~schaerli/traits_draft/traitsDraft.pdf
(Please not that this is still a *draft* version)


> 	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.

As I said above, a new Trait can be built from zero or more other
Traits. Thereby, it is possible to access overridden and conflicting
methods implemented in the Subtraits. Therefore, you can build a Trait
TTranslucentColor from a trait TColor without any code duplication or
code copying.

> 	2. Traits introduces another type of behavior object.  
> So now you have classes and traits to deal with, which adds 
> complexity.

As I describe in the latest version of the paper, the fact that multiple
inheritance uses classes in multiple roles (namely as instance
generators and as primitive entities of code reuse) is precisely one of
the main problems of this approach. Thus, I believe that the concept of
having a more primitive entity for reuse of behavior is very important.
Please read in the paper for a more detailed explanation why.

Nathanael



> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Anthony Hannan
> Sent: Monday, November 18, 2002 7:10 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: Classes as Packages (was: Harvesting infrastructure)
> 
> 
> 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/ECOOP2
> 002Traits.
> 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
> 




More information about the Squeak-dev mailing list