Hi -- On Tue, 12 Nov 2002, Eric Schwartz wrote: > Joel VanderWerf <vjoel / PATH.Berkeley.EDU> writes: > > # if method lookup for Point fell through to Space, we'd > > # be able to do this, which is senseless: > > #p tl.bottom_right > > That's not what I'm talking about, though I can see how you got > there. I'm saying that it makes no sense to define a class inside a > module, and then have to include the module's namespace inside > itself. To me, this looks needlessly redundant: > > module Foo > class Bar > include Foo > def bah > thingy() > end > end > > (assuming thingy() is defined in module Foo elsewhere) > > I just defined Bar inside Foo, why should I have to include it all > over again? It's not really 'again'; defining a class and including a module are very different operations. You've defined a class (Foo::Bar), but you haven't yet indicated, prior to the 'include', that you want the instance methods defined in a particular module (Foo) to be instance methods of that class. Like any class, Foo::Bar has to set up its instance methods and method search chain explicitly, by inheritance, method definition, and/or module inclusion. All of which may sound like an elaborate way of saying, "You have to" :-) But the model is very consistent. If classes started knowing what else was defined in their enclosing modules -- not just knowing, but adding such methods to their instances -- things could get very messy.... I agree that stylistically it does feel a little weird for a class to include the module in which it itself is defined. The best thing would probably be to do a little design tweaking: module Foo module FooMod def thingy puts "Hi, I'm here" end end class Bar include FooMod end end Foo::Bar.new.thingy # Hi, I'm here Here, Foo::Bar is on the same level as the module it includes, which probably has a better feel to it. David -- David Alan Black home: dblack / candle.superlink.net work: blackdav / shu.edu Web: http://pirate.shu.edu/~blackdav