On Sun, Dec 5, 2010 at 4:54 PM, Rick DeNatale [email protected]
wrote:
There’s a much simpler explanation IMHO.
…
Thanks for the detailed explanation.
The ‘things’ pointed to by klass pointers are either:
Could this be a typo where you intended to say ‘super’ pointers?
class objects (like Array, Hash, Object etc) if they are marked by
a flag that they are ‘virtual’ then they are not returned by methods
like class, superclass, ancestors, etc.
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’
$ irb
ruby-1.9.2-head > class A < Object; end
=> nil
ruby-1.9.2-head > A.singleton_class
=> #
ruby-1.9.2-head > A.singleton_class.superclass
=> #
I suppose I should really turn this into a blog article.
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.
On Mon, Dec 6, 2010 at 3:00 AM, Rick DeNatale [email protected]
wrote:
If I see correctly, those are really different things. The klass
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).
On Sun, Dec 5, 2010 at 11:49 PM, Rick DeNatale [email protected]
wrote:
…
The ‘things’ pointed to by klass pointers are either:
Could this be a typo where you intended to say ‘super’ pointers?
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 in 1.8.7
class B < A
end
B.superclass # => A
b_sing = class << B; self; end
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 # => #Class:Class
and even more confusing to me …
b_sing.superclass.superclass # => #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).
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.
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.
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?
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.
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.
which found in the mtab of the metaclass ARE shared in the case where
i.e. the third definition of meta here.
is a form of class used to describe a class. A singleton class used
Note 1: If I understand correctly, for an object that is not
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?