On 31 août 05, at 06:03, Julian Fitzell wrote:

> Quoting Nick Brown <maillist at bredon-gill.demon.co.uk>:
>
>> So I was thinking that traits might help me here to 'flesh out' the
>> collection protocol on top of some bare bones of state. I'll admit  
>> that
>> I haven't looked very deeply at this, but have I misunderstood what
>> traits are about?
>>
>
> Yes.  This is one of my favourite possible uses for traits.  This  
> is basically
> what Ruby lets you do with its Enumerable module (though it does it  
> with
> mixins): http://www.rubycentral.com/book/ref_m_enumerable.html
>
> I think it's awesome... you just have to implement #do: (in Ruby's  
> case it's
> actually #each), add the right trait, and suddenly you have #collect:,
> #select:, #findAllSuchThat:, #withIndexDo:, etc, etc.

EXACT!

> I want traits just so that I can have an Enumerable trait. :)  Ruby  
> also has a
> similar mixin module called Comparison which provides #<, #>, etc.  
> as long as
> you provide #<=>, which returns -1, 0, or 1 as a basic ordering  
> method.  It
> seems pretty common to have a whole bunch of methods that can be  
> provided
> based on a common implementation of a few "core" methods (these  
> tend to be the
> #subclassResponsibility methods in my abstract classes).  The  
> problem is, of
> course, if you have an object that wants to be Comparable and  
> Enumarable and
> have a bunch of other shared behaviours as well.

I hope that we will make it :)
Because this is one of the goal. Getting a better way of structuring  
our classes

Stef
>
> Julian
>
> -- 
> julian at beta4.com
> Beta4 Productions (http://www.beta4.com)
>
>