traits (the other ones) vs. mixins

[Ara.T.Howard]

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

 

[Joel VanderWerf]

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.

 

[David Naseby]

Ara.T.Howard wrote:
...

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.

 

[Ara.T.Howard]

They do; as I have (partially) written up on
http://homepages.ihug.com.au/~naseby/33.html

Traits are mixins, just exceedingly polite ones.

i apologize for not reading this earlier! i must agree that this sounds like
one of those things that's deemed a good idea because it's an abstraction that
promotes reuse. the funny thing is that, in my experience, abstraction sits
atop a fine line and too much can kill. like most things the middle path
seems best.

so - do you mind that i stole the traits name? some seemed to have. ;-)

cheers.

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

 

[Mike Austin]

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

 

[David Naseby]

On Thu, 5 May 2005, David Naseby wrote:


i apologize for not reading this earlier! i must agree that this sounds like
one of those things that's deemed a good idea because it's an abstraction that
promotes reuse. the funny thing is that, in my experience, abstraction sits
atop a fine line and too much can kill. like most things the middle path
seems best.

so - do you mind that i stole the traits name? some seemed to have. ;-)

Its not my name to give. I just tried to implement the concept in a
blog article, and never released a formal module to the Ruby community
to carve it into the Ruby namespace. So from that angle, you're
welcome to it.

Traits are a fringe concept, IMO - you aren't subsuming a name that is
well known, but the word does have a prior, researched meaning in CS.
So you are muddying the waters if you do go with Traits.

And Mike: creating explicit entities, in this case, means creating
concrete classes from a series of mixins and base classes. So if you
want a ColouredCircle class, and have the Circle and Colour mixins,
you create a concrete class by mixing in the Circle and Colour mixins:
ie:
class ColouredCircle
include Circle
include Colour
end

As Joel pointed out, with Ruby Mixins, there can be a difference in a
ColouredCircle implementation composed of Circle and Colour modules,
depending on the order of inclusion. Traits (that are not Ara's try
to ensure that the order of inclusion is unimportant.

 

[gabriele renzi]

Mike Austin ha scritto:

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.