Here are a few links:

General Overview:
http://www.iam.unibe.ch/%7Escg/Research/Traits/index.html
(links to some key papers on traits)

Overview of Squeak Implementation:
http://www.iam.unibe.ch/~schaerli/smalltalk/traits/traitsPrototype.htm
(includes very helpful screenshots of traits in action)

SqueakMap:
http://map1.squeakfoundation.org/sm/package/0aa65fd8-aabb-4e46-9000-626361ddc65a

You look at this stuff and have to wonder of Traits might not be a nice 
arrow to have in the quiver for modularizing the image.

It would be great to get a rough, pseudo coded example from a Traits 
proponent on what a Traits-based solution might look like for making 
Networking in Squeak cleaner and more modular (too choose an arbitrary 
example). Let's say there were 3 competing networking frameworks, call 
them "StandardNetworking", "RefactoredNetworking", and "Flow". How might 
a Traits-based solution look for making the competing frameworks 
pluggable? If, say, FileList2 decided to make the switch from 
"StandardNetworking" to "Flow", would Traits help?

It might persuade some more people to promote Traits on "The big 
priority list in the sky" if it looks like it would help with some of 
the other big priorities.

At any rate, it's easy to see how Traits might provoke some strong 
feelings.

David P Harris wrote:
> stéphane ducasse wrote:
> 
>> Yes please do it, but read the %$%$#$%#X papers and try.
>> We even did an example with complex number to show how we can reuse code
> 
> 
> Can you please point me to the papers again?  I have looked through them 
> previously, and at the time, I thought Traits would be an excellent 
> addition to Squeak.
> Thanks,
> David
> 
> 
> 
>