[ACCEPTED]-Instance methods in modules-instance

Think about what aux is. What object will respond 19 to aux? It's an instance method, which means 18 that instances of classes that include ModName 17 will respond to it. The ModName module itself 16 is not an instance of such a class. This 15 would also not work if you had defined ModName 14 as a class — you can't call an instance 13 method without an instance.

Modules are very 12 much like classes that can be mixed into 11 other classes to add behavior. When a class 10 mixes in a module, all of the module's instance 9 methods become instance methods of the class. It's 8 a way of implementing multiple inheritance.

They 7 also serve as substitutes for namespaces, since 6 each module defines a namespace. But that's 5 somewhat unrelated. (Incidentally, classes 4 also have their own namespaces, but making 3 it a class implies that you'll create instances 2 of it, so they're conceptually wrong for 1 that purpose.)

You can do it this way:

module ModName
  def aux
    puts 'aux'
  end
  module_function :aux
end

and then just call 1 it:

ModName.aux

You can also say

module ModName
  extend self

  def aux
    puts 'aux'
  end
end

Then you can include the 2 module normally, but also call methods via 1 ModName.

the module definition evaluates to 'this 34 is...', why?

In Ruby, everything is an expression, there 33 are no statements or declarations. Which 32 means that everyhing evaluates to a value. (However, this 31 doesn't necessarily mean that it evaluates 30 to a useful value. For example, the puts method always 29 evaluates to nil, just like a def method definition 28 expression (except in Rubinius, where the 27 def expression evaluates to a CompiledMethod object for the 26 method being defined).)

So, if everything 25 evaluates to a value, what should a module 24 definition expression evaluate to? Well, there 23 are a couple of candidates: it could evaluate 22 to nil, just like a method definition expression. Or 21 it could evaluate to the module object itself, after 20 all, this is what we are defining, right? But 19 actually, Matz chose a third option: module 18 (and class) definition expressions actually 17 evaluate to whatever the last expression 16 inside the module definition body evaluates 15 to. (This allows you to easily simulate 14 the other two possibilities by just putting 13 nil or self as the last expression inside a module 12 definition body.)

In your case, the last 11 expression inside the module definition 10 body is an assignment. But, an assignment? What 9 the heck does that return? Isn't that a statement? No, not 8 in Ruby. Everything is an expression, and assignments 7 are no exception: assignment expressions 6 evaluate to whatever the right hand side 5 evaluates to. Here, the right hand side 4 of the assignment expression is a string 3 literal, which evaluates to a string object.

So, the 2 entire module definition expression evaluates 1 to the string 'this is a const in module'.

And a little more...

module Y
  def Y.a
    puts "a"
  end

  def Y.b
    c
  end

  def self.c
    puts "b -- c"
  end
end

call (without '.new'):

Y.a #=> "a"
Y.b #=> "b -- c"
Y.c #=> "b -- c"

0

class Foo
  include ModName
end
Foo.new.aux
# output: aux

0