From: "Ara.T.Howard" Date: 2005-05-11T01:35:29+09:00 Subject: [RFC] traits-0.1.0 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 ===============================================================================