On Fri, Jun 02, 2006 at 12:27:32AM +0900, ara.t.howard / noaa.gov wrote:
> On Thu, 1 Jun 2006, Mauricio Fernandez wrote:
>
> thought i'd just chime in here and show how this would be done with traits
> since it has overlapping aims:
> 
[...] 

Please indulge some quick questioning on my part; all the answers are in the
sources but my eyeballs hurt a bit atm. and I'd prefer to avoid reading
traits-0.9.1.rb's ~700 lines of code :-) After a cursory look, it's clear
traits and SuperClass are in different leagues. SuperClass goes for minimalism
and meta-programming self-restraint (no methods added to core classes, no
hooks used...); traits seems to do so much more and pays the cost (I can see a
load of methods/instance variables being added at Object's level,
Object.singleton_method_added, etc.).

>     harp:~ > cat a.rb
>     require 'traits'
>     class MyClass
>       include TraitInit
>       trait_initialize 'a', 'b'
>       def sum() a + b end
>     end

Would  def sum; @a + @b end   also work?
Plain instance variables are the main appeal of SuperStruct or SuperClass.
 
> >Unlike Struct.new, you can use SuperClass to generate classes in the middle
> >of the inheritance chain:
> >
[...]
>     harp:~ > cat a.rb
>     require 'traits'
> 
>     class X
>       include TraitInit
>       trait_initialize
>       trait :foo => 1
>     end
> 
>     class Y < X
>       trait :bar, :baz => 10
>       trait(:foo){ baz + 1 }
>       def fubar() foo + baz end
>     end
>
>     p Y.new(:bar => 10, :baz => 1).foo
>     p Y.new(:bar => 1).fubar

Interesting.  Can this be made to work if X is defined as 
  class X
    attr_reader :foo
    def initialize(foo); @foo = foo end
  end
and doesn't include TraitInit, or when it does something non-trivial in
#initialize?  In other words, is it possible to have a single class in the
hierarchy use traits' trait_initialize without touching the rest?

And is the block evaluated every time one calls #foo, or only once?

One last question: does trait provide some mechanism to create #==, #hash and
#eql?, and if so, are they static-ish (only considering instance
variables/traits at the moment they were created) or dynamic (taking into
account traits defined later)? I hesitated about which one would be better,
and finally added both to SuperClass, but maybe there's something for/against
one of them.

Thanks,

-- 
Mauricio Fernandez  -   http://eigenclass.org   -  singular Ruby