From: "Chr. Rippel" <chr_news@...>
Date: 2002-01-23T10:13:01+09:00
Subject: Re: ruby 2.0; rubicon

"Mathieu Bouchard" <matju@sympatico.ca> wrote in,
....
> I don't know. Not sure why Module.constants is useful anyway.

You can you use them to distinguish constants defined in different
scopes - so something like #constants_scoped might be more
descriptive
-----
def minus (b )
  eval (%{puts(Module.constants - Object.constants).sort.join(", ")}, b)
end

A0 = 1
module A
   B = 'B'
   class C
   D = 'D'
  end
  class E
    F = 'F'
  end
end

minus binding        # =>
module A
   minus  binding    # => B,C,E
   class C
      minus  binding # => B,C,D,E
   end
   class E
      minus binding  # => B,C,D,F
   end
end
-----

> > 3. No for the third assert.  Unlike inheritance, "include" copies
> >    module attributes into a class/module, so that even if the included
> >    module (ModY) does include new module (ModX), it doesn't affect the
> >    module (ModZ).  It's known restriction that would not be fixed in
> >    the near future.
>
> I'm disappointed. (and this suggests that the list of directly included
> modules is not kept, and instead the list of _all_ included modules is
> kept, which somehow disallows #included_modules(false)).
>
....
If you really think about it, by making including transitive (and
anti-reflexive) you end up with a partial inclusion order, in other
words an oriented cycle free graph, introducing the same problems
and advantages of ordinary multiple inheritance - i.e. the lookup
path ambiguities have to be resolved by an priori artificial ordering
of edges of the inclusion graph - akin to Python's inheritance
strategy.
Frankly, I was never persuaded by the argument that Ruby's mixin
strategy is superior to multiple inheritance other then, but not
unimportant, simplicity of implementation.

/Christoph