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