"Dave Thomas" <dave / pragprog.com> schrieb im Newsbeitrag
news:267B6CF2-25A0-11D8-92F7-000A95676A62 / pragprog.com...
>
> On Dec 3, 2003, at 5:46, Christoph wrote:
>
> > T. Onoma wrote:
> > ...
> >>
> >> How are mix-in more restricted than multiple inheritance?
> >
> > There is non such thing as a diamond shape
> > mixin graph ...
> >
>
> Actually, that's not really true.
>
> module A; end
> module B; include A; end
> module C; include A; end
> class D; include B; include C; end
>
> You can build as complicated a mixin graph as you can a MI graph. The
> difference is that because mixins are modules, they don't have their
> own state, but instead parasitically use the state of the class into
> which they are mixed.

U sure about that?  Try this:

module B
  def initialize
    super
    @foo = "bar"
  end
end

class X
  include B

  def initialize
    super
    @bar = "foo"
  end
end

p X.new.instance_variables

> This eliminates the underlying issue with MI,
> where there may be two _instances_ (logically) of the class at the top
> of the diamond.

The MI issue is eliminated by not using classes as scopes for instance
variables and not declaring instance variables: @foo denotes the same
variable, regardless which module uses it.  In fact, super class methods
can easily access instance variables that are introduced further down the
inheritance hierarchy.

Kind regards

    robert