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 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.
···
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.
--
David Naseby
http://homepages.ihug.com.au/~naseby/
David Naseby 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
···
On 5/5/05, Joel VanderWerf <vjoel@path.berkeley.edu> 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. 
cheers.
-a
···
On Thu, 5 May 2005, 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/~naseby/33.html
Traits are mixins, just exceedingly polite ones.
--
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
===============================================================================
<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.
···
On 5/5/05, Ara.T.Howard@noaa.gov <Ara.T.Howard@noaa.gov> wrote:
On Thu, 5 May 2005, David Naseby wrote:
--
David Naseby
http://homepages.ihug.com.au/~naseby/
Mike Austin ha scritto:
David Naseby 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.
···
On 5/5/05, Joel VanderWerf <vjoel@path.berkeley.edu> wrote: