Mike Austin ha scritto:
> David Naseby wrote:
> 
>> On 5/5/05, Joel VanderWerf <vjoel / path.berkeley.edu> wrote:
>>
>>> Ara.T.Howard wrote:
>>> ...
>>>
>>>>  - Traits can be composed: trait composition is symmetric and 
>>>> conflicting
>>>>  methods are excluded from the composition
>>>
>>>
>>> ...
>>>
>>>> i cannot see how this differs from mixins?  for example:
>>>
>>>
>>> The operation of mixing in modules is not commutative.
>>>
>>> class C1
>>>   include M1
>>>   include M2
>>> end
>>>
>>> class C2
>>>   include M2
>>>   include M1
>>> end
>>>
>>> C1 and C2 may have radically different behavior. I guess using ruby
>>> modules as traits in this sense would require either some checking in
>>> #module_included, or some global registry of which modules are allowed
>>> to define which methods.
>>
>>
>> They do; as I have (partially) written up on 
>> http://homepages.ihug.com.au/~naseby/33.html
>>
>> Traits are mixins, just exceedingly polite ones.
> 
> 
> While on the subject of traits, can someone explain the the last part of 
> this paragraph, where he says you must create explicit entities?
> 
> "As an example, assume that we would like to use a traditional
> mixin implementation (such as Jam [3]) to write a class
> that provides the behaviour corresponding to the mixins Circle,
> Color, Visual, and Serializable. In order to do that, we
> have to define a particular order such as Circle вк Color вк
> Visual вк Serializable, create explicit entities ColoredCircle,
> VisualColoredCircle, SerializableVisualColored-
> Circle, and spread the necessary glue code among all of them."

well, I think the basic thing they're talking about is the need to call 
a mixin method from another, and to handle name conflicts in a sane way.

The way they're thinking of solving it may relate to the fact that (I 
suppose) Jam is a java-with-mixins and so it would require some diferent 
practice from those found in duynamic languages.