Any official name for Ruby's class which makes "class methods"?

[Hunt Jon]

We all know Ruby really doesn't have class methods.

But how do you call such classes that have "class methods"?
I hear Japanese say =E7=89=B9=E7=95=B0 class, but is there any English word=
for that?

Is eigenclass an official name for that?

Trying to figure it out by looking into documentation, but I haven't found
any official call.

- J

 

[Marnen Laibow-Koser]

We all know Ruby really doesn't have class methods.

But how do you call such classes that have "class methods"?
I hear Japanese say 特異 class, but is there any English word for that?

You mean instances of class Class? The official docs call them
metaclasses.

Is eigenclass an official name for that?

I think -- and I could be confused -- that "eigenclass" is a synonym for
"singleton class". I never use the word myself, so I'm not certain.

Trying to figure it out by looking into documentation, but I haven't
found
any official call.

- J

Best,

 

[Ryan Davis]

We all know Ruby really doesn't have class methods.
=20
But how do you call such classes that have "class methods"?

This question is different from your subject.

A class that has class methods is just called a class. So I shall assume =
that the word "make" in the subject is the actual key to your =
question...

Assuming I interpret the question correctly, the question itself is =
flawed. Since ruby isn't metacircularly defined, there isn't a class =
that makes/creates class methods (or singleton methods on a class =
instance... I shall call them class methods). Either the parser creates =
them when it loads and evals a file, or the methods are dynamically =
created at runtime via one of many methods.

If you're instead asking "what's the name of the final destination of a =
class method?" then ... yeah. prolly eigenclass or metaclass. I prefer =
to think of them simply as "class methods" and not worry about it.

Trying to figure it out by looking into documentation, but I haven't = found
any official call.

yeah. I think that is partially because the slightly mislabeled "class =
method" is good enough for most of us and we simply haven't needed a =
more accurate term for 99% of our discussions.

 

[Marnen Laibow-Koser]

Hi --



I don't think that's right. String and Array and

class MyClass

and Class.new are all instances of Class, but they're not metaclasses.

I thought it was strange too, but take a look:
http://www.ruby-doc.org/core-1.8.7/classes/Class.html

Actually, I think it was Jim Weirich who pointed out that, given the
usual sense of the term "metaclass" as a class which produces other
classes, Class itself is the only metaclass in Ruby.

I think he's right, but that's not the sense in which the official docs
use the term.

[...]

David

Best,

 

[Marnen Laibow-Koser]

It says:

All metaclasses are instances of the class `Class'.

but it does not say that all instances of Class are metaclasses

But I think that is what is meant. How else does the diagram on that
page make sense? Every class has an associated metaclass of the same
name in that diagram. What is that if not the Class object?

That would make "metaclass" a synonym for "class", which wouldn't make
sense.

I think that "metaclass" is here a synonym for the Class object, as
opposed to the class declaratio or anything else.

David

Best,

 

[Rick DeNatale]

Actually, I think it was Jim Weirich who pointed out that, given the
usual sense of the term "metaclass" as a class which produces other
classes, Class itself is the only metaclass in Ruby. The term is
sometimes used to refer to singleton classes in general, and sometimes
to refer only to singleton classes of Class objects:

I usually don't disagree with my younger friend Jim, but...

In general, although in some languages the implementation of
metaclasses is involved with creating other classes, the more general
meaning is that a metaclass is a class whose instance(s) are classes.
Granted Ruby is a bit sneaky in this regard since the class METHOD
sometimes hides the klass linkage, but if you look at ruby
documentation such as
http://www.ruby-doc.org/core-1.8.7/classes/Class.html you'll see that
it talks about multiple metaclasses, and although it point's out that
the vertical lines in the diagram represent inheritance, it leaves the
description of the horizontal lines, which link Object to (Object),
OtherClass to (OtherClass) etc. These are of course the klass
pointers, and despite the smoke thrown by the class method which skips
over 'virtual/singleton' classes,

It might be of interest to note that early Smalltalk versions had only
one metaclass and it was Class, but this was limiting because it meant
that all classes had to have the same message protocol, since the
metaclass is where the method dictionary used to find methods for a
class lives, much as the String class is where the method dictionary
used to find methods for instances of strings is stored (of course I'm
simplifying a bit here, these are really where the first method
dictionary consulted is found before looking for inherited methods).

So, in Smalltalk at least, the first step in making Metaclasses more
'First class' was to allow each class to have its own metaclass,

And in Smalltalk metaclasses don't create other classes, much as in
Ruby, when a class is created, by sending it the subclass:... method,
a metaclass for the new class is created automatically, so it's the
other way around really.

The real role of a metaclass is to serve as the class of its sole
class instance, much like (singleton) classes serve as the class of
their instance or instances.


Now Smalltalk-80 makes Metaclasses more apparent, and factors things
by Having a class Hierarchy like this

Object
Behavior - provides the minimal state necessary for objects that
have instances.
It is really the interface with the VM. For
Smalltalk this is where the
instance variables for the method dictionary, the
superclass link,
and the form of instances (Smalltalk instances can
contain either
a sequence of either object pointers, bits, bytes or words,
and this sequence may be fixed or variable in length.
ClassDescription - this is the interface to the IDE and the compiler,
it provides instance variables for naming the 'Class',
naming the instance variables, and for a comment
shown in the browser
Class - adds support for things like class variable names,
and shared pool dictionaries which provide for something
like Module scoped names in Ruby
Metaclass - primarily this adds the behavior needed to create a new
Metaclass, initialize it and link it into the
parallel inheritance hierarchy.

Now Ruby doesn't have an equivalent for ClassDescription, and might
not have a class named Metaclass, but if you account for that, the
inheritance/instance-of diagram in the official document of Class
looks very much like the same diagram for Smalltalk with the
appropriate removals.

The real difference is that Ruby makes an attempt to hide the "Man
behind the curtains." and Smalltalk makes the "wizard" visible, and
refactors him into multiple bits.

--
Rick DeNatale

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

 

[Rick DeNatale]

But I think that is what is meant. =A0How else does the diagram on that
page make sense? =A0Every class has an associated metaclass of the same
name in that diagram. =A0What is that if not the Class object?


I think that "metaclass" is here a synonym for the Class object, as
opposed to the class declaratio or anything else.

Then how does the sentence before the sentence you originally quoted make s=
ense:

In the diagram that follows, the vertical arrows represent
inheritance, and the parentheses meta-classes. All metaclasses are
instances of the class `Class=92.

There are lots of parenthesized 'metaclasses' and none ARE Class.

--=20
Rick DeNatale

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

 

[Xavier Noria]

I wonder if there's still no metaclass accessor in 1.9 to avoid
picking a name .

 

[Marnen Laibow-Koser]

Then how does the sentence before the sentence you originally quoted
make sense:

In the diagram that follows, the vertical arrows represent
inheritance, and the parentheses meta-classes. All metaclasses are
instances of the class `Class�.

There are lots of parenthesized 'metaclasses' and none ARE Class.

I took the parenthesized items on the diagram to be the actual Class
objects, while the nonparenthesized items were the classes that most
programmers are more likely to interact with.

It's strange, I know, but I really can't think of an interpretation that
makes more sense.

Best,

 

[David A. Black]

Hi --

But I think that is what is meant. How else does the diagram on that
page make sense? Every class has an associated metaclass of the same
name in that diagram. What is that if not the Class object?

The metaclasses are anonymous. The metaclass (or whatever we call it)
of String, for example, is a completely separate class/object from
String:
=> 1143780

I think that "metaclass" is here a synonym for the Class object, as
opposed to the class declaratio or anything else.

Class is itself an object (and a class). But it is definitely not the
metaclass/singleton class of any other object:
=> 1148540


David

 

[David A. Black]

I usually don't disagree with my younger friend Jim, but...

Let's detach it from Jim unless he chimes in himself. I mentioned him
because I thought I remembered hearing this characterization from him,
but if there are inaccuracies in what I'm saying I don't want history
to record them as having come from Jim.


David

 

[David A. Black]

Hi --

I took the parenthesized items on the diagram to be the actual Class
objects, while the nonparenthesized items were the classes that most
programmers are more likely to interact with.

It's strange, I know, but I really can't think of an interpretation that
makes more sense.

They're all instances of Class, and thus all actual Class objects.

Every Ruby object has what I sometimes call a "birth" class (String
for "abc", Class for Object, etc.), and then in addition, every object
(almost) may, optionally, have a singleton class. The singleton class,
which is anonymous, exists for the purpose of serving as the
repository of singleton methods for this object, and to provide a node
on the method lookup path where modules can be included for this
object only.

It's kind of a nature/nurture thing. The original nature of the object
is represented by its "birth" class. The nurture of the object -- the
processes by which it branches away from what would otherwise have
been the entirety of its identity -- is carried out via its singleton
class. (Of course, this analogy doesn't take into account the fact
that the "birth" class can change dynamically. But it's a good start.)

Matz has always emphasized that the main thing here is the
individuation and dynamism of objects, and that the two-class model is
just a way to implement that dynamism. He's even discussed in the past
the possibility of doing it some other way in the future, though my
recent understanding is that the two-class way is probably here to
stay, at least for the foreseeable future. And it works really well,
partly because you get the same interface to the singleton class that
you do to the "birth" class (the class keyword).


David

 

[Florian Frank]

And I dislike this usage. The whole problem seems to stem from a general
confusion of the meaning of the term meta programming (where
eigen/singleton/virtual classes ofen play a role in Ruby) with the fact,
that Matz couldn't yet decide how to call these thingies. But some day,
eventually...

I usually don't disagree with my younger friend Jim, but...

In general, although in some languages the implementation of
metaclasses is involved with creating other classes, the more general
meaning is that a metaclass is a class whose instance(s) are classes.

Do you have found any other examples of these classes whose instances
are classes besides Class? I haven't. If you try to create instances
like this
TypeError: wrong instance allocation
from (irb):2:in `new'
from (irb):2

or even this
TypeError: wrong instance allocation
from (irb):4:in `new'
from (irb):4

Ruby does a hard type check and throws an exception. This is where you
have broken through Ruby's thin layer of abstraction around its
C-internals, while Smalltalk is much more turtles all the way down.

This is different from Module, BTW:
# => nil

So you could say, Ruby has one metaclass, but can have lots of metamodules.

 

[Florian Frank]

The metaclasses are anonymous. The metaclass (or whatever we call it)
of String, for example, is a completely separate class/object from
String:

Yes. And these things, that shall never be named, aren't much like
classes either: They cannot create any instances for example. In Ruby
terminology they are much closer to modules in the sense, that they are
containers of methods, that are used to extend objects.

 

[Florian Frank]

The metaclasses are anonymous. The metaclass (or whatever we call it)
of String, for example, is a completely separate class/object from
String:

Yes. And these things, that shall never be named, aren't much like
classes either: They cannot create any instances for example. In Ruby
terminology they are much closer to modules in the sense, that they are
containers of methods, that are used to extend objects.

 

[Rick DeNatale]

Actually no I didn't. I believe that it was David A. Black.

I've been standing off from this thread. I'm writing a blog article,
which I've been meaning to for at least a year, called "The object
which must not be named" I hope to publish it soon.


--
Rick DeNatale

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

 

[David A. Black]

Hi --

Yes. And these things, that shall never be named, aren't much like
classes either: They cannot create any instances for example. In Ruby
terminology they are much closer to modules in the sense, that they are
containers of methods, that are used to extend objects.

I could definitely imagine 'singleton module' instead of 'singleton
class'. I think Matz has commented on this choice but I can't remember
any details.


David

 

[Gary Wright]

I could definitely imagine 'singleton module' instead of 'singleton
class'. I think Matz has commented on this choice but I can't remember
any details.

I was thinking along the same lines while reading this thread. There
are a few characteristics that seem to argue for class implementation
vs a module implementation:

-- the class/instance relationship doesn't have an analog
with modules and an object can be viewed as an "instance"
of its singleton class

-- the inheritance relationship of classes provides a
structure for searching singleton classes of classes that
also no analog with modules

These aren't strong reasons for a class implementation over a module
implementation but it seems like a module implementation would involve
adding special case semantics to the 'singleton modules' that aren't
as 'special' in the current singleton class implementation.

Gary Wright