From: David Naseby <naseby@...>
Date: 2005-05-05T10:46:48+09:00
Subject: Re: traits (the other ones) vs. mixins

On 5/5/05, Ara.T.Howard@noaa.gov <Ara.T.Howard@noaa.gov> wrote:
> On Thu, 5 May 2005, David Naseby wrote:
> 
<snip />
> >
> > They do; as I have (partially) written up on
> > http://homepages.ihug.com.au/~naseby/33.html
> >
> > Traits are mixins, just exceedingly polite ones.
> 
> i apologize for not reading this earlier!  i must agree that this sounds like
> one of those things that's deemed a good idea because it's an abstraction that
> promotes reuse.  the funny thing is that, in my experience, abstraction sits
> atop a fine line and too much can kill.  like most things the middle path
> seems best.
> 
> so - do you mind that i stole the traits name?  some seemed to have.  ;-)
> 

Its not my name to give. I just tried to implement the concept in a
blog article, and never released a formal module to the Ruby community
to carve it into the Ruby namespace. So from that angle, you're
welcome to it.

Traits are a fringe concept, IMO - you aren't subsuming a name that is
well known, but the word does have a prior, researched meaning in CS.
So you are muddying the waters if you do go with Traits.

And Mike: creating explicit entities, in this case, means creating
concrete classes from a series of mixins and base classes. So if you
want a ColouredCircle class, and have the Circle and Colour mixins,
you create a concrete class by mixing in the Circle and Colour mixins:
ie:
  class ColouredCircle
    include Circle
    include Colour
  end

As Joel pointed out, with Ruby Mixins, there can be a difference in a
ColouredCircle implementation composed of Circle and Colour modules,
depending on the order of inclusion. Traits (that are not Ara's ;) try
to ensure that the order of inclusion is unimportant.

-- 
David Naseby
http://homepages.ihug.com.au/~naseby/