Classes as Packages (was: Harvesting infrastructure)

Anthony Hannan ajh18 at cornell.edu
Tue Nov 19 15:48:20 UTC 2002


"Andrew P. Black" <black at cse.ogi.edu> wrote:
> At 23:55 -0500 11/18/2002, Anthony Hannan wrote:
> >	I think that is my whole point: abstract behaviors and traits are
> > analogous.
> Yes, you've got it!
> > So why add a new way of defining behavior and putting
> > them together, yielding two types of behaviors and composition in the
> > same system.
> Why? Because you can't define abstract behaviour in Smalltalk.  That 
> is, you MUST specify a superclass when you declare an abstract class. 
> Of course, you are not *required* to declare new instance variables, 
> but there is no way to restrict programmers from doing so, or from 
> accessing inherited instance variables in the supposedly "pure" methods.
> (OK, you can declare an abstract class with nil as its superclass. 
> But try and inherit from it and have things work -- ugh).

You can have abstract behavior in Smalltalk (nil superclass), you just
can't instantiate from it without also inheriting from Object.  And in
the multiple inheritance I'm proposing instance variables don't exist.

> So, if you fix those two problems, you get what we call traits.

Or you get what I call multiple inheritance without state.

> If you like, think of traits as lobotomized classes that have
> 	- no superclass and
> 	- no state and
> 	- can't be instantiated.

Likewise for abstract behaviors.

> >  Even in the future work section of the Traits paper, they
> >talk about replacing single inheritance and adding state to traits.  This
> >would wrap them back around to multiple inheritance but in a nested
> >composition form instead of an inheritance form, which would basically
> >be the same thing.
> 
> This is future work, and highly speculative.  But nesting and 
> inheritance are NOT the same thing.

I think it is basically the same.  From how you describe your nested
traits, methods that subtraits provide are visible to users of the
composite trait, unless the composite trait overrides it somehow.  I
call that inheritance.

> The other contribution of traits, apart from the above restrictions 
> (are restrictions a contribution?) are the combination operations: 
> symmetric composition as well as overriding composition.  We also add 
> exclusion and aliasing operations on traits.  Neither is strictly 
> necessary, but both are useful.  For example, if you have defined a 
> trait that is just what I want but has two extra methods, I could
> 	(1) ask you to refactor it into two traits, one trait with 
> the two extra methods and one trait with the rest, so that I can use 
> the second trait and not the first; or
> 	(2) use it as you provide it, and override the two extra 
> methods with "Self shoulNotImplement"; or
> 	(3) use exclusion to remove the extra methods.
> (3) seemed easiest for the programmer.

2 and 3 seems analagous to me.  But we could implement the same type of
exclusion expression when inheriting if we want.  In fact, we can add
aliasing and the other type of combination operations to inheritance
just as well, but I don't think they're needed.

> Converting a class to a trait *would be* difficult if Nathanael had 
> not automated it!  One method (executed for you by the browser) will 
> convert a class, and as many of its superclasses as you want, into a 
> trait.

That shows traits and behaviors are basically the same, so why make them
different.  Remember, I'm proposing multiple inheritance without
instance variables, and allowing abstract behaviors that can't be
instantiated.

Cheers,
Anthony



More information about the Squeak-dev mailing list