From: gabriele renzi Date: 2005-05-05T14:24:43+09:00 Subject: Re: traits (the other ones) vs. mixins Mike Austin ha scritto: > 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." 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.