Pickaxe: "Top-Level Execution Environment"

G

Greg Weeks

I have a bone to pick with the generally-wonderful Pickaxe regarding
"Top-Level Execution Environment", which states:

At the top-level, we're executing in the context of some predefined
object [of class Object]. When we define methods, we're actually
creating (private) instance methods for class Object.

The second sentence is true and helpful. But the first sentence is only
sort of true, and only because of some unexplained magic. Here's what I
mean.

I'm not aware that "in the context of some ... object" has an
established meaning other than what "instance_eval" does; and
"instance_eval" does not provide a context for constant definitions.
Also, "instance_eval" interprets "def"s in the context of the
singleton-class of the object (I think), which is inconsistent with the
second (correct) sentence.

The second sentence remedies both of these deficiencies. But the
consistency of the two sentences requires some magic: Most code of
interest is evaluated in the context of "class Object ... end", AND self
is not Object.

Mightn't it be better to have self == Object at the top-level? Then no
magic would be required.

PS: My interest in eliminating the magic is that I built up some very
bad intuition from seeing methods invoked in their definition context.
It would have helped a lot if I had initially seen:

def foo ; "foo" ; end # a method of all objects
foo # same as self.foo; and self (ie, Object) is an object

This is tricky. But because it is not magical, it teaches something
useful.
 
T

Trans

I have a bone to pick with the generally-wonderful Pickaxe regarding
"Top-Level Execution Environment", which states:

At the top-level, we're executing in the context of some predefined
object [of class Object]. When we define methods, we're actually
creating (private) instance methods for class Object.

The second sentence is true and helpful. But the first sentence is only
sort of true, and only because of some unexplained magic. Here's what I
mean.

I'm not aware that "in the context of some ... object" has an
established meaning other than what "instance_eval" does; and
"instance_eval" does not provide a context for constant definitions.
Also, "instance_eval" interprets "def"s in the context of the
singleton-class of the object (I think), which is inconsistent with the
second (correct) sentence.

The second sentence remedies both of these deficiencies. But the
consistency of the two sentences requires some magic: Most code of
interest is evaluated in the context of "class Object ... end", AND self
is not Object.

Mightn't it be better to have self == Object at the top-level? Then no
magic would be required.

A fair suggestion, but I bet three was a reason. Personally think they
should be separate things altogether. You can always add to Object,
but this "magic" prevents us from creating top-level methods without
infecting all other objects. I 'd rather see an implied:

module Main
extend self

...code...

end

T.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,968
Messages
2,570,154
Members
46,702
Latest member
LukasConde

Latest Threads

Top