From: "Ara.T.Howard" Date: 2005-05-05T05:54:51+09:00 Subject: traits (the other ones) vs. mixins from these: http://www.iam.unibe.ch/~scg/cgi-bin/oobib.cgi?query=nathanael+traits+composable+units+ecoop http://www.cantrip.org/traits.htmlhttp://www.cantrip.org/traits.html and snippets like: - A trait provides a set of methods that implement behaviour - A trait requires a set of methods that parameterize the provided behaviour - Traits do not specify any state variables, and the methods provided by traits never directly access state variables - Traits can be composed: trait composition is symmetric and conflicting methods are excluded from the composition - Traits can be nested, but the nesting has no semantics for classes -- nested traits are equivalent to flattened traits i cannot see how this differs from mixins? for example: jib:~ > cat a.rb module DoubleSizeTrait def double_size 2 * size end end module QuadrupleSizeTrait include DoubleSizeTrait def quadruple_size 2 * double_size end end class Array include QuadrupleSizeTrait end p(Array::new(10).quadruple_size + 2) jib:~ > ruby a.rb 42 and ruby itself already ships with many mixins that meet these criteria. except for part 4 above, which i don't really get - mixins sure be, at least, a super-set of traits aren't they? they would cease to be traits if you set and instance var or something... but that's quibbling no? i guess you could do someting with the 'parameterize' bit by requiring the methods used within traits to be specified in some ctor in a factory type setup - but why bother to confine them that way instead of just using duck typing on the object the trait is used in? -a -- =============================================================================== | email :: ara [dot] t [dot] howard [at] noaa [dot] gov | phone :: 303.497.6469 | renunciation is not getting rid of the things of this world, but accepting | that they pass away. --aitken roshi ===============================================================================