I see them as a mild form of inheritance. I remember first bumping
into traits when I first worked with Self a few months ago. The language
makes them sound pretty natural. As an aside, some say (and I mostly
agree) that traits account for most of the useful use cases of
multiple inheritance.

Anyway, I think they can be really effective at reducing code duplication.

--
Giuliano Mega <giuliano at ime.usp.br>

> I would say they are more like "include" in Ruby. With Java  
> interfaces, you still need to code the implementation of the methods,  
> whereas with Traits, you are incorporating the functionality of those  
> methods. Sort of like "including" a library of methods.
>
> - Daniel
>
> On Sep 3, 2005, at 1:50 PM, Eric Goebelbecker wrote:
>
>> So, at the risk of oversimplifying, are traits very similar to
>> interfaces in Java?
>>
>> On 9/3/05, Tom Phoenix <rootbeer at redcat.com> wrote:
>>
>>> On 9/3/05, Alan Grimes <alangrimes at starpower.net> wrote:
>>>
>>>
>>>> The first issue is that I have hardly a clue as to what is meant  by a
>>>> "trait". It was never mentioned in any of the classes I took or  in 
>>>> any
>>>> of the textbooks I have read on my own time.
>>>>
>>>
>>> They're a relatively new concept in Smalltalk. The general idea (and
>>> somebody correct me if I'm wrong) is that a trait can become an
>>> ancestor to a class without being a class itself. That is, a trait is
>>> a dictionary of related methods; you may use most or all of those
>>> methods without further modification in programming a class.
>>>
>>> For a real-world-ish example, if I were making an Automobile  object, I
>>> would need to include methods to allow a key to open or start the
>>> Automobile. Similarly, if I were making an Apartment or a Locker, I
>>> would need methods to allow a key. But instead of making all of those
>>> inherit from LockableObject, I could have a trait for Lockability.  Any
>>> object with that trait has methods understanding, say, that the wrong
>>> key doesn't work in the lock.
>>>
>>> So, why not make all of those inherit from LockableObject? Because  the
>>> Automobile inherits from Vehicle, which may or not be a
>>> LockableObject. The others don't have lockable ancestors either. We
>>> don't want to make all of the ancestor classes lockable, and we don't
>>> want to duplicate the lockability code in each of the classes that
>>> needs it.
>>>
>>> In other words, when traits are available, you may inherit some
>>> methods from ancestor classes, and some from ancestor traits. The
>>> traits allow you to share ancestor methods without having to have a
>>> common ancestor with those methods.
>>>
>>> Hope this helps!
>>>
>>> --Tom Phoenix
>>>
>>>
>>>
>>
>>
>> -- 
>> Back when I was a boy, we carved our own IC's out of wood.
>>
>> Eric Goebelbecker
>> eric at ominor.net
>> http://eric.ominor.net
>>
>>
>
>