# Shouldn't it be class \>\> self , or am I dyslexic?

**URL:** <https://www.ruby-forum.com/t/shouldnt-it-be-class-self-or-am-i-dyslexic/113520>\
**Category:** Ruby\
**Created:** [September 1, 2007, 3:24am UTC](https://www.ruby-forum.com/t/shouldnt-it-be-class-self-or-am-i-dyslexic/113520 "2007-09-01T03:24:34Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![nbits](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/8c91f0/32.png) [@nbits](https://www.ruby-forum.com/u/nbits)\
**Post date:** [September 1, 2007, 3:24am UTC](https://www.ruby-forum.com/t/shouldnt-it-be-class-self-or-am-i-dyslexic/113520/1 "2007-09-01T03:24:34Z")

</div>

This is the correct title, uh, I think…

dyslexic me 🙂

---

<div class="post-metadata">

**Author:** ![nbits](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/8c91f0/32.png) [@nbits](https://www.ruby-forum.com/u/nbits)\
**Post date:** [September 1, 2007, 4:21pm UTC](https://www.ruby-forum.com/t/shouldnt-it-be-class-self-or-am-i-dyslexic/113520/2 "2007-09-01T16:21:14Z")

</div>

Ben T. pisze:

> This is the correct title, uh, I think…
> 
> dyslexic me 🙂

The \<\< direction is correct (and intuitive IMHO), given:

class A \< B  
end

This can do two things, either creates and opens class A extending class  
B or reopens class A if it already exits (in the second case the  
superclass is optional, but if given it must match the existing class  
superclass)

now, given:

s = “some\_string”

class \<\< s  
end

What this does ? it either creates and opens singleton class for s  
instance or reopens the singleton it if it already exits. Since  
singleton classes dont have their names you could also imagine  
\<anonyous\_name\> between class and \<\< tokens here.

The only question that could arise is: why there are two different  
tokens (\<\< and \<) ?. I think Matz wanted to syntactically differentiate  
how to deal with classes and metaclasses.

lopex

---

<div class="post-metadata">

**Author:** ![nbits](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/8c91f0/32.png) [@nbits](https://www.ruby-forum.com/u/nbits)\
**Post date:** [September 1, 2007, 4:29pm UTC](https://www.ruby-forum.com/t/shouldnt-it-be-class-self-or-am-i-dyslexic/113520/3 "2007-09-01T16:29:14Z")

</div>

Marcin Mielżyński wrote:

> What this does ? it either creates and opens singleton class for s  
> instance or reopens the singleton it if it already exits. Since  
> singleton classes dont have their names you could also imagine  
> \<anonyous\_name\> between class and \<\< tokens here.

Yes, but there is a major difference between those two. In the former  
case A  
inherits from B, but in the latter case the singleton class does _not_  
inherit from self, self inherits from the singleton class (well actually  
self  
is an instance of the singleton class, but the point is that self is  
based on  
the class and not the other way around), so Ben has a point when he  
says,  
that the arrows should point in the other direction.

---

<div class="post-metadata">

**Author:** ![nbits](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/8c91f0/32.png) [@nbits](https://www.ruby-forum.com/u/nbits)\
**Post date:** [September 2, 2007, 5:49pm UTC](https://www.ruby-forum.com/t/shouldnt-it-be-class-self-or-am-i-dyslexic/113520/4 "2007-09-02T17:49:51Z")

</div>

Consider the following excerpt from Programming Ruby (2nd Ed.):

* * *

Class Definition

class [scope::] classname [\< superexpr]  
body  
end

class \<\< obj  
body  
end

A Ruby class definition creates or extends an object of class Class by  
executing the code in body. In the first form, a named class is created  
or extended. The resulting Class object is assigned to a constant named  
classname (see below for scoping rules). This name should start with an  
uppercase letter. In the second form, an anonymous (singleton) class is  
associated with the specific object.

* * *

It is only the second form that concerns us. Notice how the author makes  
no mention of inheritance, he simply states that “an anonymous  
(singleton) class is associated with the specific object.” Indeed, it  
would be strange to say instead  
something like “an anonymous (singleton) class is derived from the  
object” because inheritance is a relation between two classes, not an  
object and a class. It seems to me that your inheritance-based  
understanding of singleton classes replaces the author’s original words  
with this bizarre, alternative explanation.

I say “strange” and “bizarre” rather than “wrong” because the  
distinction between classes and objects is somewhat blurred in Ruby, and  
especially so in the example I gave previously, where “self” is an  
instance of Class. In that context, class \<\< self might be thought of as  
a form of dynamic inheritance  
because self is a class. The problem with that thought is that it  
ignores the  
semantics of the construction, which is to add behavior to the value of  
the  
right-hand operand, “self,” by constructing (or extending) an anonymous  
class and adding a reference to that class to the value of “self.” It  
does not matter whether the singleton class is constructed or extended  
because in each case the  
value of “self” does not contribute to the singleton class, it is the  
singleton class that contributes to the value of “self.”

But what about: class \<\< object, where object is not a class? As I said  
above,  
calling this inheritance seems to me to stretch the notion beyond its  
proper limits. And, of course, the “semantical” objection I stated in  
the previous paragraph applies with at least as much force in this case.  
Whether the RHS is  
an object or a class, the effect of the operation is to introduce new  
functionality via the LHS and add it to the RHS, which is why the arrows  
should point toward the RHS.

nbits

Marcin Mielży�?ski wrote:

> Ben T. pisze:
> 
> > This is the correct title, uh, I think…
> > 
> > dyslexic me 🙂
> 
> The \<\< direction is correct (and intuitive IMHO), given:
> 
> class A \< B  
> end
> 
> This can do two things, either creates and opens class A extending class  
> B or reopens class A if it already exits (in the second case the  
> superclass is optional, but if given it must match the existing class  
> superclass)
> 
> now, given:
> 
> s = “some\_string”
> 
> class \<\< s  
> end
> 
> What this does ? it either creates and opens singleton class for s  
> instance or reopens the singleton it if it already exits. Since  
> singleton classes dont have their names you could also imagine  
> \<anonyous\_name\> between class and \<\< tokens here.
> 
> The only question that could arise is: why there are two different  
> tokens (\<\< and \<) ?. I think Matz wanted to syntactically differentiate  
> how to deal with classes and metaclasses.
> 
> lopex

---

<div class="post-metadata">

**Author:** ![nbits](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/8c91f0/32.png) [@nbits](https://www.ruby-forum.com/u/nbits)\
**Post date:** [September 2, 2007, 7:59pm UTC](https://www.ruby-forum.com/t/shouldnt-it-be-class-self-or-am-i-dyslexic/113520/5 "2007-09-02T19:59:46Z")

</div>

Hi –

On Mon, 3 Sep 2007, Ben T. wrote:

> term. If the RHS were the same as its class (which is impossible), then  
> Marcin would be right, because the singleton class would be subclassing  
> the RHS. But no instance is ever the same as its class. What is really  
> going on is that we are  
> augmenting the interface of the RHS by decorating its most derived class  
> with an anonymous class to which RHS has exclusive access, thus  
> effectively adding the methods of the singleton class to the RHS. As the  
> recipient of these new methods, RHS is on the receiving side of the  
> operation, which is why ‘class \>\> RHS …’ is more intuitive than ‘class  
> \<\< RHS … .’

I’m sorry, but I had to chuckle at the use of the word “intuitive”  
after that explanation 🙂

I wouldn’t think of class \<\< obj as having anything at all to do with  
inheritance. It’s more like this, in terms of how the class keyword  
works:

class expr

where expr can be:

A  
A \< B  
\<\< arbitrary\_object

So the inheritance \< is more like:

class (A \< B)

and the singleton notation is more like:

class (\<\< obj)

Remember, also, that the class keyword isn’t itself a class  
identifier; you’re not looking for “the class that is \>\> object”, but  
the class that is, so to speak, yielded from object. (Or something.)  
It’s not a notation that relates very closely to any other.

David

---

<div class="post-metadata">

**Author:** ![nbits](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/8c91f0/32.png) [@nbits](https://www.ruby-forum.com/u/nbits)\
**Post date:** [September 2, 2007, 7:25pm UTC](https://www.ruby-forum.com/t/shouldnt-it-be-class-self-or-am-i-dyslexic/113520/6 "2007-09-02T19:25:59Z")

</div>

I like it when people agree with me, and according to the diagram on  
page 384 of Programming Ruby, you are basically correct to say that  
“self inherits from the singleton class.” The diagram shows that a  
“virtual” (singleton) class is inserted into the inheritance hierarchy  
for self (or whatever the RHS happens to be) as an immediate subclass of  
the most derived, non-singleton, class of which the RHS is an instance  
whenever ‘class \<\< RHS …’ is executed. So even if we think of the ‘\<\<’  
as an “inheritance operator,” it is still pointing in the wrong  
direction! But is inheritance really the right concept here? Notice that  
the singleton class is inserted below the most specific class of the RHS  
term. If the RHS were the same as its class (which is impossible), then  
Marcin would be right, because the singleton class would be subclassing  
the RHS. But no instance is ever the same as its class. What is really  
going on is that we are  
augmenting the interface of the RHS by decorating its most derived class  
with an anonymous class to which RHS has exclusive access, thus  
effectively adding the methods of the singleton class to the RHS. As the  
recipient of these new methods, RHS is on the receiving side of the  
operation, which is why ‘class \>\> RHS …’ is more intuitive than ‘class  
\<\< RHS … .’

Sebastian H. wrote:

> Marcin Mielżyński wrote:
> 
> > What this does ? it either creates and opens singleton class for s  
> > instance or reopens the singleton it if it already exits. Since  
> > singleton classes dont have their names you could also imagine  
> > \<anonyous\_name\> between class and \<\< tokens here.
> 
> Yes, but there is a major difference between those two. In the former  
> case A  
> inherits from B, but in the latter case the singleton class does _not_  
> inherit from self, self inherits from the singleton class (well actually  
> self  
> is an instance of the singleton class, but the point is that self is  
> based on  
> the class and not the other way around), so Ben has a point when he  
> says,  
> that the arrows should point in the other direction.

---

<div class="post-metadata">

**Author:** ![nbits](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/8c91f0/32.png) [@nbits](https://www.ruby-forum.com/u/nbits)\
**Post date:** [September 2, 2007, 9:10pm UTC](https://www.ruby-forum.com/t/shouldnt-it-be-class-self-or-am-i-dyslexic/113520/7 "2007-09-02T21:10:29Z")

</div>

unknown wrote:

> Hi –  
> Perhaps you were misled by the first sentence of my reply to Sebastian,  
> in which  
> I said ‘you are basically correct to say that “self inherits from the  
> singleton class.”.’ Note the “basically” qualification. Apart from that  
> sentence, my entire exposition prior to this reply, which spans two  
> postings, argues _against_ the idea that “\<\<” signifies inheritance in:

class \<\< object  
…  
end

In pseudocode, this translates into:

object.method1 # error  
object.method2 # error

1. temp = Class.new { method1, method2, … }
2. temp.superclass = object.class
3. object.class = temp

object.method1 # OK  
object.method2 # OK

Thus 1-3 might be more succinctly expressed as:

Class.new { method1, method2 } \>\> object

which is very close to:

class \>\> object # instead of class \<\< object  
def method1  
…  
end

def method2  
…  
end  
end

Got it?

nbits

> I’m sorry, but I had to chuckle at the use of the word “intuitive”  
> after that explanation 🙂
> 
> I wouldn’t think of class \<\< obj as having anything at all to do with  
> inheritance. It’s more like this, in terms of how the class keyword  
> works:
> 
> class expr
> 
> where expr can be:
> 
> A  
> A \< B  
> \<\< arbitrary\_object
> 
> So the inheritance \< is more like:
> 
> class (A \< B)
> 
> and the singleton notation is more like:
> 
> class (\<\< obj)
> 
> Remember, also, that the class keyword isn’t itself a class  
> identifier; you’re not looking for “the class that is \>\> object”, but  
> the class that is, so to speak, yielded from object. (Or something.)  
> It’s not a notation that relates very closely to any other.
> 
> David