traits (the other ones) vs. mixins

Discussion in 'Ruby' started by Ara.T.Howard, May 4, 2005.

  1. Ara.T.Howard

    Ara.T.Howard Guest

    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
    ===============================================================================
     
    Ara.T.Howard, May 4, 2005
    #1
    1. Advertising

  2. 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.
     
    Joel VanderWerf, May 4, 2005
    #2
    1. Advertising

  3. Ara.T.Howard

    David Naseby Guest

    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.

    --
    David Naseby
    http://homepages.ihug.com.au/~naseby/
     
    David Naseby, May 4, 2005
    #3
  4. Ara.T.Howard

    Guest

    On Thu, 5 May 2005, 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.


    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
    ===============================================================================
     
    , May 4, 2005
    #4
  5. Ara.T.Howard

    Mike Austin Guest

    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
     
    Mike Austin, May 4, 2005
    #5
  6. Ara.T.Howard

    David Naseby Guest

    On 5/5/05, <> wrote:
    > On Thu, 5 May 2005, David Naseby wrote:
    >

    <snip />
    > >
    > > 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. ;-)
    >


    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.

    --
    David Naseby
    http://homepages.ihug.com.au/~naseby/
     
    David Naseby, May 5, 2005
    #6
  7. 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.
     
    gabriele renzi, May 5, 2005
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Martin Maney

    Calling __init__ for all mixins

    Martin Maney, Aug 18, 2004, in forum: Python
    Replies:
    4
    Views:
    427
    Michael Hudson
    Aug 19, 2004
  2. Joshua Spoerri

    mixins that don't down-call?

    Joshua Spoerri, Aug 10, 2005, in forum: Python
    Replies:
    0
    Views:
    289
    Joshua Spoerri
    Aug 10, 2005
  3. mk
    Replies:
    1
    Views:
    473
    Bruno Desthuilliers
    Feb 17, 2010
  4. ray
    Replies:
    1
    Views:
    1,430
    Robert Kern
    Jun 4, 2010
  5. Daniel

    Mixins and overloading

    Daniel, Jul 15, 2011, in forum: C++
    Replies:
    1
    Views:
    260
    Sunil Varma
    Jul 15, 2011
Loading...

Share This Page