From: Robert Dober <robert.dober@...>
Date: 2007-10-24T21:24:27+09:00
Subject: Re: Ruby-Traits 0.2 released (sorry long)

On 10/24/07, Trans <transfire@gmail.com> wrote:
>
>
> On Oct 23, 4:16 pm, "Robert Dober" <robert.do...@gmail.com> wrote:
> > Hi list
> >
> > after some very interesting input I decided to rewrite Ruby-Traits completely.
> >
> > http://rubyforge.org/frs/?group_id=4642&release_id=15737
> >
> > I have decided to implement two different kinds of traits:
> > * ruby-traits
> > and
> > * pure-traits.
> >
> > In detail:
> > * ruby-traits are mimicking some of the properties of traits but violate the
> > flattening property. They implement some of the more dynamic features
> > of modules and are in fact module based. The code is heavily influenced
> > by Thomas Sawyer's traits from Facets. Many thanks to Thomas for the
> > permission to use his code. Note that Thomas' traits of Facets is yet another
> > different beast.
> >
> > * pure-traits implement traits in the strict sense of their definition
> > here:http://portal.acm.org/ft_gateway.cfm?id=1028771&type=pdf&coll=GUIDE&d...
> >
> > They obey the flattening property, using a trait is exactly as defining
> > its methods inline, no modules are used and inheritance is unchanged.
> > All trait combination rules are obeyed (associative, communative, e.g.)
> >
> > The main purpose of pure-traits is to play around with them and to see the
> > benefits and shortcomings of traits based design.
> >
> > The syntax has changed, again inspired by Factes, trait aliasing is done
> > via #* now, thus traits aliased and combined can be expressed more
> > naturally:
> >   t1 * { :t1_a => :a } + t2 * { :t2_a => :a }
> > works now as expected.
> >
> > In addition to the traditional trait operations +, - and *, I have
> > implemented & to allow of selective usage of methods.
> > I believe that the usage of this is normally a bad sign for the design
> > but sometimes it might be a handy feature.
>
> [snip]
>
> Whew! Yep, long, but interesting. I'll have to check the ruby-traits
> code and see if there's any cross-pollination to be had. Seems like
> maybe the main difference between this and Facets is the use of the
> Traits < Module class (where as Facets just extends Module). I'm also
> curious about the & method.
>
> Great work!
Well thanks ;)
to make your live a little bit easier, I decided to subclass Module
because I needed some state for correct conflict detection and I did
not want to pollute the Module instance variable space.
AAMOF you can naively compute the conflicting methods of two modules like this

m1.instance_methods & m2.instance_methods, however that will give
false conflicts for the diamond shape inclusion:

m = Module::new { def a; 42 end }
m1 = m + Module::new{}
m2 = m + Module::new{}
m3 = m1 + m2 ## a is not a conflict

In order to detect this I need state, at least I could not figure out
how to do it dynamically, well walking up the ancestors array should
work but I'd rather not go through that trouble. Hmm maybe I should...

And & is just an idea stolen from Daniel and Mauricio ;)

Cheers
Robert