A
Ara.T.Howard
i'm having quite a time deciding what to do with traits. i first released as
'attributes' but some complained that
attribute 'foo'
and
class_attribute 'bar'
were just too long. to remedy that i switched to 'trait' - a synonym for
attribute. however, as it's been pointed out, that name currently has a
meaning in cs to some people. my current thoughts are
random thoughts for traits/against attributes:
- trait is short
- traits is a synonym for attribute (attr, attr_accessor, etc)
- i like the word 'role' to describe what others are calling traits. the
perl6 guys use this too so any future impl of 'traits' (the other ones)
as 'roles' wouldn't likely suprise anyone
- 'traits' (the other ones) are of dubious value to ruby. it's been shown
that they can be easily implemented in ruby - yet no one is using them.
their value, to me, seems largely academic and smells of
hyper-abstraction (read obfusication). however, i can easily imagine
situations where they might be extremely appropriate and wouldn't want
to steal the name. does anyone who might plan on needing it object to
using 'roles' for that concept?
random thoughts for attributes/against traits
- no confusion with other traits
- the alias 'has' can make 'attribute' plenty short (the current version
of traits uses this alias too btw.)
one other thing, the impl of traits was suprisingly hard. the tricky bit was
implementing defaults and inheritence in the general case of class methods,
instance methods, singleton methods (on objects not classes, and module
methods. the difficult bits revolved around being able to these things
singleton_super
class C
class << self
p singleton_super #=> C
end
end
class << []
p singleton_super #=> <#Array:1234567>
end
detecting singleton-ness
class C
p singleton? #=> false
class << self
p singleton? #=> true
end
end
p singleton? #=> false
class << []
p singleton? #=> true
end
deciding where to look for defaults
class A
trait 'x' => 42
end
class B < A
trait 'x' # clearly our default comes from A
end
module M
traits 'x' => 42
end
class C
include M # clearly our def AND default comes from A
end
a = []
class << a
trait 'foo' => 'bar' # our defaults must come from ourselves (no
# inheritence)
end
class A
class_trait 'x' => 42
trait 'x' => 'forty-two'
end
class B < A
# clearly get def and default of class x from A
# clearly get def and default of __instance__ x from A!
end
b = B::new
b.x = nil
p b.x # don't get default from A now!
anyhow - these are the kinds of confusing things anyone reading the code
will see being addressed.
and any code review would be appreciated. the code is pretty non-trivial and
un-commented - but it is brief. you'd need a complete understanding of
singleton (or whatever) classes to review it. one thing i plan on doing is
pulling alot of the __trait_XXX methods out of Object and into a specialized
module to avoid polluting the Object namespace : the current approach of
prefacing everything with __trait_XXX was just to get it working. feel free
to ping my offline.
any comments appreciated. sorry for confusion - i generally don't have a hard
time coming up with a decent name for a project but this one's stumped me.
people have expressed interest in me gem-izing traits so i'd like to pin it
down a bit before doing so.
kind regards.
ps. urls for project:
http://raa.ruby-lang.org/search.rhtml?search=traits
http://codeforpeople.com/lib/ruby/traits
-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
===============================================================================
'attributes' but some complained that
attribute 'foo'
and
class_attribute 'bar'
were just too long. to remedy that i switched to 'trait' - a synonym for
attribute. however, as it's been pointed out, that name currently has a
meaning in cs to some people. my current thoughts are
random thoughts for traits/against attributes:
- trait is short
- traits is a synonym for attribute (attr, attr_accessor, etc)
- i like the word 'role' to describe what others are calling traits. the
perl6 guys use this too so any future impl of 'traits' (the other ones)
as 'roles' wouldn't likely suprise anyone
- 'traits' (the other ones) are of dubious value to ruby. it's been shown
that they can be easily implemented in ruby - yet no one is using them.
their value, to me, seems largely academic and smells of
hyper-abstraction (read obfusication). however, i can easily imagine
situations where they might be extremely appropriate and wouldn't want
to steal the name. does anyone who might plan on needing it object to
using 'roles' for that concept?
random thoughts for attributes/against traits
- no confusion with other traits
- the alias 'has' can make 'attribute' plenty short (the current version
of traits uses this alias too btw.)
one other thing, the impl of traits was suprisingly hard. the tricky bit was
implementing defaults and inheritence in the general case of class methods,
instance methods, singleton methods (on objects not classes, and module
methods. the difficult bits revolved around being able to these things
singleton_super
class C
class << self
p singleton_super #=> C
end
end
class << []
p singleton_super #=> <#Array:1234567>
end
detecting singleton-ness
class C
p singleton? #=> false
class << self
p singleton? #=> true
end
end
p singleton? #=> false
class << []
p singleton? #=> true
end
deciding where to look for defaults
class A
trait 'x' => 42
end
class B < A
trait 'x' # clearly our default comes from A
end
module M
traits 'x' => 42
end
class C
include M # clearly our def AND default comes from A
end
a = []
class << a
trait 'foo' => 'bar' # our defaults must come from ourselves (no
# inheritence)
end
class A
class_trait 'x' => 42
trait 'x' => 'forty-two'
end
class B < A
# clearly get def and default of class x from A
# clearly get def and default of __instance__ x from A!
end
b = B::new
b.x = nil
p b.x # don't get default from A now!
anyhow - these are the kinds of confusing things anyone reading the code
will see being addressed.
and any code review would be appreciated. the code is pretty non-trivial and
un-commented - but it is brief. you'd need a complete understanding of
singleton (or whatever) classes to review it. one thing i plan on doing is
pulling alot of the __trait_XXX methods out of Object and into a specialized
module to avoid polluting the Object namespace : the current approach of
prefacing everything with __trait_XXX was just to get it working. feel free
to ping my offline.
any comments appreciated. sorry for confusion - i generally don't have a hard
time coming up with a decent name for a project but this one's stumped me.
people have expressed interest in me gem-izing traits so i'd like to pin it
down a bit before doing so.
kind regards.
ps. urls for project:
http://raa.ruby-lang.org/search.rhtml?search=traits
http://codeforpeople.com/lib/ruby/traits
-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
===============================================================================