关于Ruby中OBJECTS的问题

Question

I'm reading 'metaprogramming in ruby'

its such an EXCELLENT book. Seriously, it talks about stuff that I never hear mentioned elsewhere.

I have a few specific questions however about objects (I'm in the first few chapters)

1. I understand that the RubyGems gem installs the method 'gem' to the module Kernel so that it shows up on every object. Is there a reason they didnt put it into the Object class?

2. He talks about how when ruby looks for the method it always goes right then up. What exactly does 'up' mean? I see it in the diagram, its just that I dont really understand the purpose of 'up'. he doesnt explain that part much.

3. What is the point of the Object class? How come those methods cant be just placed into Class? If every object belongs to a class (even if its Class), then what is the point of object, basicobject, and kernel?

4. String, Array, blah blah are obviously an instance of Class. Class is also an instance of itself. So if Class is an instance of Class.... how does it also inherit from Object? Where in the code does it relates to BOTH Class and Object?

5. I know kernel contains methods such as puts that can be used everywhere, and this relates to question 1, but why cant they just condense it and put it all into Object... where it would seem everything inherits from object anyway

Answer 1

1. Both would work, but typically methods on Object should only be methods that deal with a particular object. Puting things in the Kernel module are less about about object and more global.

2. I assume it means "up the inheritance chain". So it looks for the method on the child class, then on that classes parent class until it finds one or runs out of parent classes.

3. Object is the base class of all objects, naturally (For ruby 1.8 at least) . The crazy part is that a class is actually an instance of the Class class. (you follow that?) So adding instance methods to Class would add methods to class objects, but not instances of those classes.

4. Nearly everything in ruby is an object. Class.superclass is actually Module (which is like a class you can't instantiate) and Module.superclass returns Object . So Class < Module < Object is the inheritance chain if the Class class. (For ruby 1.8 at least)

5. More convention than anything. Since Object can get rather HUGE, it's customary to put things into modules and then combine those modules later. If the method doesn't deal with an instance of an object directly as self then the method doesn't belong directly in Object . More global non-object instance methods like gem go in the Kernel module to signify that they are simply methods available everywhere.

---

Some more about class objects and inheritance...

class Foo < Bar
  def hi
    puts 'Hi!'
  end
end

What this does is really quite awesome. It defines a class object, of course. Now this class object is configured to have a name Foo , a parent class Bar and a method hi . This info is sort of like this class object's meta data.

Now the class object Foo itself is an instance of Class . But Foo defines a class that inherits from Bar . The Class class defines a data structure to store this meta data about a class.

You can think of the Class class sorta kinda being defined like this:

class Class < Module

  # fictional method called on class creation
  def set_meta_data(name, superclass, methods)
    @name = name
    @superclass = superclass
    @methods = methods
  end

  # fictional way in which an instance might be created
  def new
    instance = Object.new
    instance.superclass = @superclass
    instance.addMethods(@methods)
    instance
  end
end

So a class object itself would inherit from Class but it would create objects that do not.

Thinking of classes as objects can be a bit mind bending in this way, but this also why ruby is awesome.

Answer 2

For 1 and 5, pseudo-keyword commands tend to go into Kernel rather than Object.

For 2, it makes sense for sub-classes to be "down" relative to their parent class (sub literally meaning "beneath"). Therefore if you're heading for a parent class and its ancestors, you have to go "up".

For 3, an object object is not an instance of Class , it is an instance of Object .

For 4, what's wrong with something being an instance of Class and inheriting from Object? All classes inherit from Object.