On Saturday 26 February 2005 1:01 am, Cees de Groot wrote:
> > If Collections can be refactored so that the code is better  
> > understandable it is a plus for Traits (the minus would be the speed  
> > loss).
>
> It's not an 'if'. It's a fact. I haven't read the original Traits paper  
> for years, but I still remember my excitement about refactoring that  
> beast. Not only will a huge hierarchy be refactored - you'll end up with  
> gobs of reusable code. So, if you want to build a class that has  
> 'Set-ness', you can simply grab the corresponding Trait instead of having  
> to create a Set ivar and delegate all over the place. Set will be reduced  
> of just a sample class that has 'Set-ness'.

I think that it may be instructive to look at other languages and the way they 
handle mixins.

Self was already mentioned in the Traits paper, and since Jecel is on the 
squeak-dev list, I'm not going to attempt to explain how Self does things or 
how well that works. (I've never used Self, though I did co-author a Perl 
module that unifies Perl's multiple-dictionary behavior lookup with a 
slot-based scheme like Self's. If you're interested, it's called 
'Class::Prototyped'). Brian Rice can tell us how Slate does things, but I 
recall that it looks very similar to Self.

Ruby has a single-inheritance scheme much like Smalltalk's, but also adds 
'modules' which work almost exactly like including a text file that can hold 
more behavioral definitions. Of course, since Ruby doesn't require you to 
pre-declare instance variables, this also lets you have mixins that add 
instance variables as necessary (though there is no attempt at dealing with 
or even detecting name conflicts). Modules actually are nicer than text 
inclusion, as they are first class objects and so support reflection (I 
forget whether they provide a separate namespace).

In practice, these work like Traits, but without the tool support for 
analyzing or browsing.

You can mix in a module in any class or module definition. You can also 
include a module in the definition of a 'singleton' -- objects with unique, 
anonymous classes (much like the way that Etoy player objects are constructed 
most of the time).

So, for instance, to make instances of a class able to be enumerable, you mix 
in the Enumerable module.

This requires you to define at least a method called 'each', which is then 
used as an iterator by the methods that Enumerable provides:

Enumerable.instance_methods
["select", "each_with_index", "grep", "map", "find_all", "sort_by", "collect", 
"detect", "max", "to_a", "sort", "partition", "any?", "include?", "reject", 
"zip", "find", "min", "member?", "entries", "inject", "all?"]

If you want to use, say, 'max', 'min', or 'sort' you'll also have to provide a 
definition for the comparison operator '<=>'. If you then mix in the 
Comparable module, you also get the operators that can be built using '<=>'.

Comparable.instance_methods
["between?", "==", ">=", "<", "<=", ">"]

-- 
Ned Konz
http://bike-nomad.com/squeak/