From: transfire@...
Date: 2006-06-09T03:26:36+09:00
Subject: Re: Why the lack of mixing-in support for Class methods?


ara.t.howard@noaa.gov wrote:

> right.  it's just that 'inheritence' with object generally follows this
> pattern
>
>    class B
>      attr :b
>      def initialize() @b = 'bar' end
>    end
>
>    class C < B
>    end
>
>    p C.new.b #=> 'bar'
>
> which is to say there are mechanisms, namely initialize and super, for
> propagating state.  no such mechanisms exist for class based state.  if one is
> proposing an 'inherit' method (which i think is a great idea) then i think
> it's important to also toss around ideas for things like Class.class_init
> and/or Module.module_init - eg hooks that are provided to accomplish this.  my
> preferred approach now is this
>
>    module M
>      module ClassMethods
>        attr 'a'
>        attr 'b'
>      end
>      module InstanceMethods
>      end
>      def self.included other
>        other.extend ClassMethods
>        other.module_eval{ include InstaneMethods }
>        init other
>      end
>      def self.init other
>        other.a = 42
>        other.b = 'forty-two'
>      end
>    end
>
> if we don't also consider this then the situation you describe in Nitro, where
> there a muliple ways of implimenting class method mixins, will more or less
> remain if any of those methods require state - that is to say it'd be a shame
> to make every ruby developer roll his is own way of initializing the required
> state for the module methods he could mix into his classes so easily.

Okay. I see what you're saying. Thouhg, I guess I'm thinking class
variables might help as far as carrying inheritable class level state.
Class variables are going to be "fixed" and made local to the
class/module right? So they will be able to be used for a class state
state. Is that right? And I think we all agree some sort of
module-based initialization could be helpful (though *I think* it's
hard to say how you do that for instance variables without thwarting
proper OOP).

> well - you can use the 'has' interface
>
>    class C
>      has 'c' => 42
>      class_has 'b'
>    end
>
> it's just an alias - but if you hate the name...

Better! *nodes head approvingly* :)

T.