Martin Wirblat wrote:

> Here is what I think about the use of Traits in the Collection hierarchy:
>
> [SNIP]

> And that makes Collections a really bad candidate for illustrating the 
> merits of Traits. For me this looks clearly like a counter-example.
>
Hi folks, first post here in ages and ages.

This is an interesting aspect. I read the traits papers a while back (so 
I may be rusty), and was fascinated by the work on the collection 
hierarchy. Let me say that most of my use of squeak does not revolve 
around programming in the sense of producing a finished piece of 
software, but rather as a tool to play with and hopefully understand 
data that crops up in the course of my work. I usually end up with 
dozens of object explorer windows, several workspaces, chunks of code 
everywhere, a real mess on screen.

If I feel the need to start creating new classes to represent some of 
this data, I'm usually just interested in implementing the bare bones to 
get it functioning. 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.