Below. 

On Jul 21, 2013, at 3:22 PM, tim Rowledge <tim at rowledge.org> wrote:

> 
> On 21-07-2013, at 3:12 PM, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:
> 
>> So, it appears that all these are Traits, and that we currently can't browse Traits.
>> See Trait someInstance browse...
>> (In my image I have a few obsolete Traits by the way)
> 
> Are Traits used at all? Are they used meaningfully? I remember they seemed like a pretty cool idea but has any actual, useful usefulness of a useful nature been made of them? Are there tools to do anything sensible with them? Is there current, readable documentation that would help people make good use of them?
> 
> If not, toss'em.
> 
> tim

Yes, some things actually use them. Like, eh, the tests for ProfStef. Yes, they are useful, in that they provide a way to handle multiple inheritance safely. They're also documented. Let's see...

The papers are all here I think:

http://scg.unibe.ch/research/traits

One of the actual problems that can be solved (it's spoken of in one of the papers, can't recall which) is code duplication between two classes which need some common behavior, but can't inherit it because heavy dependency on their existing superclasses. In this case, you'd either have to duplicate the code in one of the parents so that the two classes could share an ancestor, or duplicate code in the two classes themselves, so that they can keep the behavior from their ancestors. 

Either way in this scenario (which the papers point out happens quite a bit in the collections hierarchy as a case study) you have to duplicate code, which really flies in the face of Ingall's rationale in Design Priniples Behind Smalltalk (a system should have as few parts as possible, and those parts should be as general as possible for simplicity and leverage, I'm paraphrasing here.)

Traits work best when applied pervasively in my opinion. This is evident in the Self language, where instead of implementing e.g. singleton behavior on a "subclass" (misnomer in this case used for brevity) of something whenever you run into wanting a singleton, you just give the object "traits oddball" and it gets singleton behavior. Done. No more writing

Foo class>>soleInstance
    ^ SoleInstance ifNil: [
        SoleInstance := self new ]

every time.

The current situation with Traits is *entirely* less of an emergency in Squeak as it was when I arrived, thanks to Andreas. Originally they were implemented in a deep meta circular way, which made them impossible to unload. He loathed this so much that he spent months on an epic reimplementation of a feature he didn't even want, supplying us with a much simpler Traits than what's in Pharo (decended from the original Squeak implementation) that still kept all of the Traits tests passing *and* could actually be unloaded.

All that said, they're pretty unloved, and mostly unused by Squeakers. Also, since our implementation is very different from that of Pharo (where traits are used throughout the system to a degree) we're liable to diverge behaviorally until they're eventually useless to everyone who isn't still running some (older) Squeak app that depended on them.

Sorry about the length of this message.