From: "David A. Black" <dblack@...>
Date: 2005-01-18T00:19:58+09:00
Subject: Re: Fwd: [suby-ruby] Your all time desired fundemental Ruby mod

Hi --

On Mon, 17 Jan 2005, trans.  (T. Onoma) wrote:

> I wrote
>
> |
> | I'm not sure I get what the problem is here.  In your examples you're
> | overriding #initialize, and calling super to invoke the old one.
> | That's pretty standard procedure -- it's what super is basically for,
> | and it seems like the simplest design.  (I'm not sure what's supposed
> | to happen in the future if instance vars become private to their
> | module.)
>
> Yes, true. But good SOC/ecapsulation meants that I should be able to modify a
> class with a module without having to adjust pre-existing parts of the class.
> For instance lets say I have class:
>
>  class C
>    def initialize
>      @y = 11
>    end
>  end
>
> I want to expand the functionality of this class with a module I have:
>
>  module M
>    def x ; @x ; end
>  end
>
> But @x needs to default to an array. So what do I do? Presently I have two
> choices. Either change M to:
>
>  module M
>    def x ; @x ||= [] ; end
>  end
>
> or use super as you suggest. But I don;t want to just recopy C for what if it
> changed internally later? So,
>
>  module M
>    def initialize
>      @x = []
>    end
>    def x ; @x ; end
>  end
>
>  class C
>    alias_method :init, :initialize
>    def initialize(*args, &blk)
>      super
>      init
>    end
>  end
>
> None of this is need though if we just had some way to "initialize_always".

I think once you've decided to include a module, you've unseparated
your concerns.  Modules you include are gray boxes rather than black
boxes; the class that includes them is adding things to its method
lookup chain, with the same implications that writing a method in the
class itself has.  It's true that you're not responsible for
implementing the module's methods (that's where the gray comes from),
but it's still part of the design of your class, and as maintainer of
the class that's part of what you have to deal with.

I think that's a strength of Ruby's design, though.  Think of it as a
resource you can draw on, rather than a snag :-)


David

-- 
David A. Black
dblack@wobblini.net