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.

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.

Julian

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