Singleton class, metaclass, eigenclass: what do they mean?

[Rick DeNatale]

...
Thanks for the detailed explanation.


Could this be a typo where you intended to say 'super' pointers?

I think I should have said klass or superclass pointers.

From my findings:

* the ancestors and the class method always hide it (as you write above)
* the 'superclass' method _does_ return the first singleton classes
pointed to by 'super'

<code>
$ irb
ruby-1.9.2-head > class A < Object; end
=A0=3D> nil
ruby-1.9.2-head > A.singleton_class
=A0=3D> #<Class:A>
ruby-1.9.2-head > A.singleton_class.superclass
=A0=3D> #<Class:Object>
</code>

That's a diference between Ruby 1.9 and 1.8 in 1.8.7

class B < A
end

B.superclass # =3D> A
b_sing =3D class << B; self; end

b_sing.superclass # =3D> #<Class:Class>

--=20
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: http://github.com/rubyredrick
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

 

[Peter Vandenabeele]

...

I think I should have said klass or superclass pointers.

If I see correctly, those are really different things. The klass
pointers for all "regular" classes (Class objects) and for virtual
classes (singleton classes (of an object) and metaclasses (of a
class), to follow your terminology) are all uniformily pointing to
the Class object, so not much to see there ... What I was
discussing is the 'super' chain that is relevant for method lookup.

That's a diference between Ruby 1.9 and 1.8 =C2=A0in 1.8.7

class B < A
end

B.superclass # =3D> A
b_sing =3D class << B; self; end

b_sing.superclass # =3D> #<Class:Class>

Indeed, I saw that too and I am confused by it ...
(that's why I only reported the 1.9.2 case that I understand).

If I understand correctly, also in ruby 1.8.7 the 'super' pointer of
the metaclass of a class, really points to the metaclass of
the superclass of that class (how else could B inherit the
class methods of A ?).

So I do not understand what this means ...
b_sing.superclass # =3D> #<Class:Class>

and even more confusing to me ...
b_sing.superclass.superclass # =3D> #<Class:Class>

It looks like there was a convention to report superclass of all virtual
classes to be #<Class:Class> (I do not understand that answer).

Thanks for all you time into this ...

Peter

 

[Rick DeNatale]

If I see correctly, those are really different things. The klass
pointers for all "regular" classes (Class objects) and for virtual
classes (singleton classes (of an object) and metaclasses (of a
class), to follow your terminology) are all uniformily pointing to
the Class object, so not much to see there ... What I was
discussing is the 'super' chain that is relevant for method lookup.

No, the klass pointer in the object header points to the beginning of
the chain of structures (in the C language sense) which point to
method tables to search for method lookup, the superclass pointer is
the 'next' link in those chains.

In the case of an object with singleton methods, klass will point to
the singleton class and it's superclass pointer will either point to
the objects 'real' class or to a chain of one or more module proxies
inserted before that class if the object has extended any module.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: http://github.com/rubyredrick
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

 

[Peter Vandenabeele]

No, the klass pointer in the object header points to the beginning of
the chain of structures (in the C language sense) which point to
method tables to search for method lookup, the superclass pointer is
the 'next' link in those chains.

In the case of an object with singleton methods, klass will point to
the singleton class and it's superclass pointer will either point to
the objects 'real' class or to a chain of one or more module proxies
inserted before that class if the object has extended any module.

I believe the confusion is that this is the case for "regular objects"
and their singleton classes, but I discussed the special case of
"class objects" and their singleton classes (aka metaclasses).

For "class objects" (e.g. class A; end), the behavior of the 'super'
pointer is different from this standard scheme, to implement
inheritance of class methods:
(A.singleton_class.superclass == A.superclass.singleton_class
and A.singleton_class.superclass != A.class).

Thanks for your time discussing this,

Peter

 

[William Rutiser]

Rick DeNatale wrote:

[snip]

As an aside, which is probably more apropos the title of this thread.
I don't personally consider singleton_class, eigenclass, and metaclass
to be equivalent terms.

In particular I reserved the term metaclass to be the 'singleton'
class of a class object. I put singleton in quotes here because,
although MRI uses the singleton class mechanism to implement
metaclasses, metaclasses are 'less' singleton when you consider that
'singleton' methods which are found in the mtab of the object's
singleton class, are not shared by any other object, class methods
which found in the mtab of the metaclass ARE shared in the case where
the class in question has one or more subclasses.

The etymology of the word metaclass is similar to that of metalanguage

meta- (also met- before a vowel or h)
combining form
1 denoting a change of position or condition : metamorphosis | metathesis.
2 denoting position behind, after, or beyond: : metacarpus.
3 denoting something of a higher or second-order kind : metalanguage | metonym.

i.e. the third definition of meta here.

and

metalanguage |ˈmetəˌla ng (g)wij|
noun
a form of language or set of terms used for the description or
analysis of another language. Compare with object language (sense 1).
• Logic a system of propositions about propositions.

So as I define it (and as is normal in most OO languages) a metaclass
is a form of class used to describe a class. A singleton class used
to describe singleton methods of an object is NOT a metaclass but
rather a singleton CLASS for that object, which inherits from the
objects original class, and is hidden from Ruby's reflection methods
because that 'virtual' bit is set.

IMHO, _why sowed a seed of confusion when he used metaclass in a way
which conflicts with the common definition, in the poignant guide.




This is true, although it's really an implementation detail. I don't
think you can detect this from Ruby without the aid of a C extension
to let you look for a singleton class without having one created
automatically as soon as you ask for it with, say class <<
self;self;end

I suppose I should really turn this into a blog article.

Is the word "singleton" used widely or at all in this sense in
connection with languages other than Ruby? I don't recall encountering
this use except for Ruby.

Do I understand that the non-existence of a singleton_class until needed
is just an implementation alternative to always having a possibly empty
singleton_class?

I am looking forward to a blog article.

 

[Josh Cheek]

[Note: parts of this message were removed to make it a legal post.]

Going through Metaprogramming Ruby, and in this book, they went with
eigenclasses. On page 119, Paolo Perrotta says

<<QUOTE
The name eigenclass has an eventful history. Each Ruby programmer seems to
have a pet name for these entities. Most people still call them singleton
classes, but this name confusingly recalls the (unrelated) Singleton design
pattern. Other people call them "metaclasses," meaning "the class of a
class." This is still a fashionable name for eigenclasses of classes, but it
doesn't really fit eigenclasses of objects.

Yukihiro "Matz" Matsumoto, the author of Ruby, hasn't announced an official
name yet -- but he seems to like the mathematically-friendly name
eigenclass. The German word eigen roughly means "one's own," so the common
translation of eigenclass is something like "an object's own class." This
book sticks with Matz's vocabulary, but be aware that the term eigenclass is
not as widely used as singleton class.

I also faced another terminology problem while writing this book: what do I
call the methods of an eigenclass? Neither eigenmethods nor eigenclass
methods is easy on the eye. After a lot of arguing and coffee drikning, I
decided to stick with Singleton Methods, which is still the most common name
for these things
QUOTE

Okay, so, a few questions, then.
1. Is this already outdated, now that there is Object#singleton_class ?
After this thread, I had taken to calling them singleton classes, but then I
got to this spot in the book, and now I'm not sure again.
2. Why do people say that singleton class is unrelated to the singleton
design pattern, when the singleton design pattern is a way to define a class
with only one instance, and an objects singleton class has the object as its
only instance?

 

[Jonas Pfenniger (zimbatm)]

1. Is this already outdated, now that there is Object#singleton_class ?
After this thread, I had taken to calling them singleton classes, but then I
got to this spot in the book, and now I'm not sure again.

It seems that 1.9 has more or less standardized on the singleton_class
and singleton_method names, but if you look into ruby's source code,
for example in class.c, you'll find an ENSURE_EIGENCLASS define or
make_metaclass method. There was a big thread on this same
mailing-list discussing the issue.

2. Why do people say that singleton class is unrelated to the singleton
design pattern, when the singleton design pattern is a way to define a class
with only one instance, and an objects singleton class has the object as its
only instance?

Maybe it's because inheriting classes also inherit of the singleton
methods defined on the parent class, but I'm making things up. I don't
remember the details. Eigenclass was cool IMO, because it's a weird
name, and make ruby special.

 

[Martin DeMello]

Eigenclass was cool IMO, because it's a weird
name, and make ruby special.

I think it's more that those of us with a maths/engineering background
found it a familiar and comfortable term.

martin

 

[Benoit Daloze]

I think it's more that those of us with a maths/engineering background
found it a familiar and comfortable term.

martin

For me, eigenclass is just weird cool.
But anyway, the choice has been made.