From: Mike Austin Date: 2005-05-05T07:49:56+09:00 Subject: Re: traits (the other ones) vs. mixins David Naseby wrote: > On 5/5/05, Joel VanderWerf 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." Thanks, Mike