Traits approaching mainstream Squeak

Daniel Vainsencher daniel.vainsencher at gmail.com
Wed Aug 31 02:01:42 UTC 2005


This sounds like a good example of Traits making reuse drastically 
easier. Basically, you would start by adding a couple of 
collection-methods to the interface, by delegation or by copy&paste. 
Then you you notice, heck, I want all of that interface. So you add a 
Trait to Collection, move lots of methods from Collection to the Trait, 
until you're satisfied.

The you add the Trait to your new class. Oops, the requires browser 
should the class suddenly turned abstract, because Trait, in order to 
provide an implementation of #collect:, requires an implementation of 
#do:. You implement that using delegation to the collection you're 
holding anyway, and voila, you're done.

Very little code is duplicated, the extra complexity from delegation is 
kept to a minimum, and all is well.

Of course the requires list might be longer, and the traits might 
already exist and not exactly match what you need, and so forth, but 
that's the general idea.

Someone made a valid point here, which is that Traits have only been 
shown to be useful for refactorings, rather than up front design.
<complete speculation>
I think that Traits are better for refactoring than inheritance, because 
all the inheritance related refactorings (push/pull method/instance 
variable and so forth) play within the basic order and structure that 
the original inheritance design determined out. It seems to me that 
decisions made using Traits are much more reversible. Therefore in the 
presence of Traits, and little inheritance, I speculate that designs (in 
the form of code) will converge to minimal duplication and minimal 
complexity faster than they do when based on inheritance.
</complete speculation>

Daniel

Nick Brown wrote:
> Sometimes I then realize that I'd like my newly
> created objects to be collection-like or stream-like. Subclassing 
> straight off one of the collection classes isn't the right thing, as it 
> brings with it instance variables to hold the collection's state - I 
> already have the state, what I want is to easily add collection-like 
> behaviour. Richard O'Keefe's enumeration adapter change set from a few 
> years back can be a big help, but it's only a partion solution. In some 
> cases I just end up duplicating as much of the collection protocol as I 
> need.
> 
> 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?
> 
> Cheers,
> Nick
> 
> P.S. I realize that what's under discussion right now is including just 
> the kernel of traits, not the actual collection refactoring, and I guess 
> that there would be still be lots of work to do to get the collection 
> traits into squeak.
> 
> 
> 
> 
> 
> 



More information about the Squeak-dev mailing list