Question about page 244 of the pickaxe

ruby-talk
1

Hello,

I have a question about Figure 19.2, page 244 in Programming Ruby.

The picture is explaining the following code:

class Guitar
def Guitar.strings()
return 6
end
def play()
…
end
…
end

lucille = Guitar.new

(Which, BTW, if `lucille’ is a reference to something, I didn’t get it. :slight_smile:

So, my question is in the picture. As I understand it, the above code
creates a Class object, Guitar, and also creates a singleton class for
Guitar. (Guitar is a class, but it’s also an object, and any object (except
immediate ones) can have a singleton class.)

If this is so, why is this picture so different from the one on the
following page, which describes how singleton classes work? Does a
singleton class sit inbetween the object and the class (like in Figure 19.3)
or does it set above the class (like in Figure 19.2)? What about the
singleton’s super pointer? It is very different in the two figures. Is
Guitar’s klass pointer really pointing to the singleton class instead of to
Class, like I thought all classes did?

Or are these two totally different situations? And if so, why were
metaclasses (as they seem to be called, though they are very rarely referred
to in this way) implemented in such a different way from how singletons are
implemented? Would it not work to make them like singletons?

Chris

2

Chris Pine wrote:

I’ll answer the important part :slight_smile: …

(Which, BTW, if `lucille’ is a reference to something, I didn’t get it. :slight_smile:

If I recall correctly, BB King calls his guitar
“Lucille”.

H.

3

Hi –

Hello,

I have a question about Figure 19.2, page 244 in Programming Ruby.

The picture is explaining the following code:

class Guitar
def Guitar.strings()
return 6
end
def play()
…
end
…
end

lucille = Guitar.new

(Which, BTW, if `lucille’ is a reference to something, I didn’t get it. :slight_smile:

So, my question is in the picture. As I understand it, the above code
creates a Class object, Guitar, and also creates a singleton class for
Guitar. (Guitar is a class, but it’s also an object, and any object (except
immediate ones) can have a singleton class.)

If this is so, why is this picture so different from the one on the
following page, which describes how singleton classes work? Does a
singleton class sit inbetween the object and the class (like in Figure 19.3)
or does it set above the class (like in Figure 19.2)? What about the
singleton’s super pointer? It is very different in the two figures. Is
Guitar’s klass pointer really pointing to the singleton class instead of to
Class, like I thought all classes did?

Every object’s “klass” pointer will point to its singleton class, if
it has one. I think this is consistent as between the two diagrams.
In 19.2, Guitar’s klass points to Guitar’, and in 19.3, a’s klass
points to a’s singleton class.

Remember that the klass chain is different from the super chain – in
fact, it’s only the former that all objects have, whereas only classes
have superclasses. The thing-that-should-point-to-Class is not
Guitar’s klass pointer, but Guitar’'s klass pointer:

Guitar
klass —> Guitar’
klass —> Class
super —> Object’

Similarly, for a (the string in 19.3):

a
klass —> singleton (anonymous)
klass —> Class

As for terminology, I think the book is using “metaclass” as a
specialized term for “singleton class of a Class object”, but I may be
wrong or only partially right about that. It’s sort of like using
“class method” as a specialized term for “singleton method on a Class
object”.

David

···

On Tue, 11 Feb 2003, Chris Pine wrote:

–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav

4

Every object’s “klass” pointer will point to its singleton class, if
it has one. I think this is consistent as between the two diagrams.
In 19.2, Guitar’s klass points to Guitar’, and in 19.3, a’s klass
points to a’s singleton class.

···

----- Original Message -----

Alright… I think I was somewhat confused, but I still don’t really feel
like my question was answered. Let’s pretend I don’t know whether obj' is the stringa’ from page 246, or the Guitar class from page 244, or any
other object. I’ll show what happens to `obj’ when we give it a singleton
class. First, we’ll assume:

obj.class # --> SomeClass
SomeClass.superclass # --> OtherClass

So here’s how things look initially:

 obj
-----
klass
  >
  >
  V

SomeClass ±–> OtherClass
--------- | ----------
super -----+

(The klass pointers in all classes points to Class, and we don’t care what
the super pointer for OtherClass is.)

Then we do something like class << obj; end' and see howobj’ changes:

 obj
-----
klass
  >
  >
  V

singleton ±–> SomeClass ±–> OtherClass
--------- | --------- | ----------
super -----+ super -----+

Again, all of the classes (including the singleton class) have their klass
pointer going to Class.

The above model is correct (as far as I know) if we are talking about
non-class object, but incorrect if we are talking about classes. The
difference is in the singleton’s super pointer. If it did work just like
with non-classes, then the super pointer of Guitar’ (Guitar’s singleton
class) would point to Class, which would be SomeClass in the above example.

Ruby really goes out of its way to prevent you from subclassing Class,
though, which is what that would be. Why is this? Why have the singleton’s
super pointer point to another singleton class? I thought the problem with
subclassing Class was that you didn’t want a subclass of Class to be
instantiated (since it would be like a class, but without Class as its
superclass, or else it would be counterintuitive), but singleton classes
can’t be instantiated, so it wouldn’t be a problem!

Chris

5

I really like replying to myself these days…

···

----- Original Message -----
Ruby really goes out of its way to prevent you from subclassing Class,
though, which is what that would be. Why is this? Why have the singleton’s
super pointer point to another singleton class? I thought the problem with
subclassing Class was that you didn’t want a subclass of Class to be
instantiated (since it would be like a class, but without Class as its
superclass, or else it would be counterintuitive), but singleton classes
can’t be instantiated, so it wouldn’t be a problem!

It looks to be coincidental. I think the reason the singleton’s super
pointer points to another singleton class is so that singleton methods can
be inherited, too.

For example, String.constants wouldn’t work, since `constants’ is defined in
Module’s singleton class, not String’s. It feels like a pretty bizarre way
to allow this sort of functionality (though I see no other way to do it).
The treating of class objects and non-class objects so differently seems…
artificial somehow. Like it was done only to allow inheritance of singleton
methods.

On the other hand, it has the “coincidental” side-effect of not allowing
Class to be subclassed, which seems to me like a deeper, more fundamental
facet of Ruby than I had previously given it credit for. Is there some
principle behind this?

Chris

6

Hi –

···

On Tue, 11 Feb 2003, Chris Pine wrote:

Then we do something like class << obj; end' and see how obj’ changes:

 obj
-----
klass
  >
  >
  V

singleton ±–> SomeClass ±–> OtherClass
--------- | --------- | ----------
super -----+ super -----+

Again, all of the classes (including the singleton class) have their klass
pointer going to Class.

The above model is correct (as far as I know) if we are talking about
non-class object, but incorrect if we are talking about classes. The
difference is in the singleton’s super pointer. If it did work just like
with non-classes, then the super pointer of Guitar’ (Guitar’s singleton
class) would point to Class, which would be SomeClass in the above example.

But the superclass of Guitar is Object, not Class. Guitar is an
instance of Class, not a subclass of it.

David

–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav

7

example.

But the superclass of Guitar is Object, not Class. Guitar is an
instance of Class, not a subclass of it.

···

----- Original Message -----

The above model is correct (as far as I know) if we are talking about
non-class object, but incorrect if we are talking about classes. The
difference is in the singleton’s super pointer. If it did work just like
with non-classes, then the super pointer of Guitar’ (Guitar’s singleton
class) would point to Class, which would be SomeClass in the above

Look at the picture I drew again. obj is Guitar. The superclass of Guitar
is irrelevant, because in general obj need not have a superclass. Meaning:
you can have a singleton class of any object, not just classes.

Assuming that obj.singleton_class returns the object’s singleton class:

‘hello’.class -----------------------> String
‘hello’.singleton_class.superclass → String

So I was tempted to say x.class == x.singleton_class.superclass for all x.
But the singleton mechanism is quite different for classes:

Guitar.class -----------------------> Class
Guitar.singleton_class.superclass → Object.singleton_class

You seem to be suggesting that these are somehow doing the same thing. (Am
I misunderstanding you?) It seems pretty clear that Ruby is handling
singleton classes of classes differently from singlton classes of other
objects. (I speculated that this was to allow inheritance of class
methods.)

Chris

8

You seem to be suggesting that these are somehow doing the same thing. (Am
I misunderstanding you?) It seems pretty clear that Ruby is handling
singleton classes of classes differently from singlton classes of other
objects.

Well, and ruby is handling classes differently from other objects.

Guy Decoux