On 3 sept. 05, at 21:42, Giuliano Mega wrote:

> 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 one we have are a bit better, since we can compose them and
correct conflicts that may occurs.

> 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.

Yes

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

Yes

>
> --
> 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
>>>
>>>
>>>
>>
>>
>>
>
>
>