[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

traits (the other ones) vs. mixins

Ara.T.Howard

5/4/2005 8:37:00 PM

6 Answers

Joel VanderWerf

5/4/2005 9:37:00 PM

0

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

5/4/2005 9:44:00 PM

0

On 5/5/05, Joel VanderWerf <vjoel@path.berkeley.edu> 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/~nase...

Traits are mixins, just exceedingly polite ones.

--
David Naseby
http://homepages.ihug.com.a...

Ara.T.Howard

5/4/2005 10:40:00 PM

0

Retoro

5/4/2005 10:47:00 PM

0

David Naseby wrote:
> On 5/5/05, Joel VanderWerf <vjoel@path.berkeley.edu> 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/~nase...
>
> 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

5/5/2005 1:47:00 AM

0

On 5/5/05, Ara.T.Howard@noaa.gov <Ara.T.Howard@noaa.gov> wrote:
> On Thu, 5 May 2005, David Naseby wrote:
>
<snip />
> >
> > They do; as I have (partially) written up on
> > http://homepages.ihug.com.au/~nase...
> >
> > 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.a...

gabriele renzi

5/5/2005 5:21:00 AM

0

Mike Austin ha scritto:
> David Naseby wrote:
>
>> On 5/5/05, Joel VanderWerf <vjoel@path.berkeley.edu> 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/~nase...
>>
>> 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.