Hi -
On Sat, 4 Aug 2007, Kenneth McDonald wrote:
Do modules not execute their own code (such as the ‘p “Testing”’) below in
their own namespace, then?
They do execute their own code, but the code being executed is an
instance method definition. Like ‘p “testing”’, the method definition
gets executed when it’s encountered. But it still has a particular
effect, namely creating an instance method for objects that use this
module.
module Run
include Test
foo
end
The above doesn’t work, for the reasons you gave, but I still don’t
understand the semantics of why not, I’m afraid. No doubt my Python way of
thinking.
[…]
Now, since that interpretation is obviously incorrect in Ruby, could someone
provide details as to what is actually going on? If possible, I prefer
explanations of the ‘behind-the-scenes’ stuff–how variables are looked up,
namespaces are defined, etc., as understanding the background mechanisms will
then make everything else pretty easy.
Basically, it works like this: every time you send a message to an
object, the object searches along a lookup path consisting of classes
and modules, looking for a corresponding method. The path includes
the object’s class, and also any modules that the class includes, and
modules included by those modules, etc.
Modules are themselves objects. That means that when you send a
message to a module, it looks for that method in its lookup path.
However, a module does not lie in its own lookup path (unless you
include it in itself).
A module (and a class) has a kind of dual identity: it’s a repository
of instance methods for other objects, and it’s also an object in its
own right. These two roles are fairly strictly delineated. You can’t
do this:
class C
def x
end
end
C.x
because x is defined for the use of instances of C, not C itself.
Similarly, you can’t do this:
module M
def x
end
end
M.x
for the same reason. And this:
module M
def x
end
x
end
is exactly the same: you’re sending the message “x” to the module
object M, but that object doesn’t have an x method.
David
