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.