# Infinite number of singleton\_classes

**URL:** <https://rubytalk.org/t/infinite-number-of-singleton-classes/18408>\
**Category:** ruby-talk\
**Created:** [15 May 2005 01:00 UTC](https://rubytalk.org/t/infinite-number-of-singleton-classes/18408 "2005-05-15T01:00:29Z")\
**Posts on this page:** 17\
**Page:** 2

<div class="post-metadata">

**Author:** ![Yukihiro\_Matsumoto2](https://avatars.discourse-cdn.com/v4/letter/y/b9e5f3/32.png) [@Yukihiro\_Matsumoto2](https://rubytalk.org/u/Yukihiro_Matsumoto2)\
**Post date:** [16 May 2005 05:43 UTC](https://rubytalk.org/t/infinite-number-of-singleton-classes/18408/21 "2005-05-16T05:43:06Z")

</div>

Hi,

> **···**
>
> In message "Re: Bug printing classes - Re: infinite number of singleton\_classes" on Mon, 16 May 2005 14:37:03 +0900, "Nakada, Nobuyoshi" \<nobuyoshi.nakada@ge.com\> writes:
> 
> > David A. Black wrote:
> > 
> > > I'd rather just see the #inspect bug fixed 🙂
> > 
> > I rather guess singleton class would not be allowed to copy, from its  
> > definition.
> 
> Agreed. Can you commit the patch?
> 
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;matz.

---

<div class="post-metadata">

**Author:** ![Christoph](https://avatars.discourse-cdn.com/v4/letter/c/eb8c5e/32.png) [@Christoph](https://rubytalk.org/u/Christoph)\
**Post date:** [16 May 2005 01:21 UTC](https://rubytalk.org/t/infinite-number-of-singleton-classes/18408/22 "2005-05-16T01:21:17Z")

</div>

David A. Black schrieb:

> :
> 
> Having a subclass able to call its superclass's singleton (class)  
> methods is, as far as I know, the only case where one object can call  
> another's singleton methods. This arrangement seems to disappear in  
> the case of singleton classes of singleton classes... but at least it  
> disappears consistently (i.e., even in the case of "Klass" above).

It also works if the subclass is an ordinary singleton class of an  
instance of the superclass.

> Or something. In practical terms there's probably not much mileage to  
> be had out of these.

True - but when there is very little mileage why not simply disallow them in  
the first place.

As a side note the class Klass lends itself naturally as the mother of all  
singleton classes - i.e. "pouch == Klass" - a problem with this idea is that  
we currently have Class \< Module \< Object.

/Christoph

---

<div class="post-metadata">

**Author:** ![Lionel\_Thiry2](https://avatars.discourse-cdn.com/v4/letter/l/74df32/32.png) [@Lionel\_Thiry2](https://rubytalk.org/u/Lionel_Thiry2)\
**Post date:** [16 May 2005 02:30 UTC](https://rubytalk.org/t/infinite-number-of-singleton-classes/18408/23 "2005-05-16T02:30:31Z")

</div>

David A. Black a écrit :

> > You have skipped this part of my post in your answer:  
> > ----8\<----  
> > And, please note this: I agree with you. There is nothing wrong or  
> > harmfull in  
> > the current behavior, while looking from the point of view of a ruby  
> > user. But I  
> > think it may be different from the point of view of a language  
> > designer and I  
> > like to take count of it.  
> > ----8\<----
> 
> I didn't have anything to add to it, so I didn't quote it back.  
> Otherwise we get into infinite recursion 🙂
> 
> > The feature is currently avaible, but unless Matz state otherwise, it  
> > is an  
> > accident, it shouldn't have never happened. Why? Because it may  
> > disapear in any  
> > future version of ruby. Who said it? Matz himself. It then should be  
> > accessible  
> > only via special module like evil.rb if one really want the feature.
> 
> If it disappears, it can't be accessible from any module, at least not  
> in exactly that form.

I should have added "Until it disapears (if it disapears), it should be  
accessible only via...". Sorry.

> > On the other hand, if it was said that ruby won't never change about  
> > singleton  
> > methods hold in singleton classes, I wouldn't care at all about this.
> 
> There's a bit of a paradox there. If Ruby shouldn't contain anything  
> that might be absent in a future Ruby, then Ruby today must be exactly  
> what Ruby in the future will be.... If singleton classes disappear,  
> lots of things will change, possibly including:
> 
> &nbsp;&nbsp;&nbsp;class \<\< obj # this form of the class keyword  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;X = 1 # constants -- where would this go?  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;def self.x # class methods on the singleton class  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;end  
> &nbsp;&nbsp;&nbsp;end
> 
> as well as just the fact that you can call Class's instance methods,  
> in general, on singleton classes.
> 
> So if you apply the rule: it should never have happened because it  
> may disappear in a future version of Ruby, then all of this should  
> never have happened and should disappear. But so should lots of other  
> things, because Matz is planning lots of changes. So that means Ruby  
> should be turned into future Ruby \*now\*. But that takes time 🙂

My "why?" argument was insuficiant, I admit it. Sorry.

Future version of ruby will change... but the ruby way/feeling will not. This is  
the garantee Matz has given us for ruby2, AFAIK. And IMO I think the presence or  
the absence of that feature matters a lot for defining that ruby way.

For example, the fact that  
----8\<----  
class \<\< obj  
&nbsp;&nbsp;X = 1  
&nbsp;&nbsp;def self.x  
&nbsp;&nbsp;end  
end  
----8\<----  
could disapear implies a lot on the ruby way.

> **···**
>
> > On Mon, 16 May 2005, Lionel Thiry wrote:
> 
> --  
> Lionel Thiry
> 
> Personal website: [http://users.skynet.be/lthiry/](http://users.skynet.be/lthiry/)

---

<div class="post-metadata">

**Author:** ![Christoph](https://avatars.discourse-cdn.com/v4/letter/c/eb8c5e/32.png) [@Christoph](https://rubytalk.org/u/Christoph)\
**Post date:** [16 May 2005 15:12 UTC](https://rubytalk.org/t/infinite-number-of-singleton-classes/18408/24 "2005-05-16T15:12:44Z")

</div>

Ara.T.Howard@noaa.gov schrieb:

> > misunderstood something once again?
> 
> well - sorta 😉
> 
> i only meant to say that the behaviour is consistent and, although there is no  
> regular ruby idiom that makes use of it now, there may well be in the future.

Actually the behavior is not consistent - assuming the definition

> **···**
>
> ----  
> public # create meta objects  
> def m(height =1)  
> &nbsp;&nbsp;&nbsp;&nbsp;height.zero? ? self : class \<\< self; self end.m(height -1)  
> end  
> ----
> 
> and the natural inheritance assumption, that the class relation
> 
> X \< Y # true, implies  
> X.m \< Y.m # true  
> ---  
> you would expect the following method lookup path for a  
> singleton class of "height" 5  
> ---  
> class A; end  
> class B \< A; end  
> b = B.new
> 
> b.m(5) \<- B.m(4) \< A.m(4) \< Object.m(4) \<  
> Class.m(3) \< Module.m(3) \< Object.m(3) \<  
> Class.m(2) \< Module.m(2) \< Object.m(2) \<  
> Class.m \< Module.m \< Object.m \<  
> Class \< Module \< Object \< Kernel  
> ---
> 
> From a practical point of view this would be rather silly, so Matz bend  
> the rules, and "benevolently ruled" the following to be true  
> ---  
> b.m(5) \< Class.m \< Module.m \< Object.m \<  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Class \< Module \< Object \< Kernel  
> ---
> 
> I personally still prefer honest exception raising over a trickery like this.
> 
> /Christoh

---

<div class="post-metadata">

**Author:** ![David\_A\_Black3](https://avatars.discourse-cdn.com/v4/letter/d/6a8cbe/32.png) [@David\_A\_Black3](https://rubytalk.org/u/David_A_Black3)\
**Post date:** [16 May 2005 01:26 UTC](https://rubytalk.org/t/infinite-number-of-singleton-classes/18408/25 "2005-05-16T01:26:55Z")

</div>

Hi --

> David A. Black schrieb:
> 
> > :
> > 
> > Having a subclass able to call its superclass's singleton (class)  
> > methods is, as far as I know, the only case where one object can call  
> > another's singleton methods. This arrangement seems to disappear in  
> > the case of singleton classes of singleton classes... but at least it  
> > disappears consistently (i.e., even in the case of "Klass" above).
> 
> It also works if the subclass is an ordinary singleton class of an  
> instance of the superclass.
> 
> > Or something. In practical terms there's probably not much mileage to  
> > be had out of these.
> 
> True - but when there is very little mileage why not simply disallow them in  
> the first place.

I'm just not ready for:

&nbsp;&nbsp;&nbsp;class \<\< obj; def self.x; end; end

to throw an error. It just seems like taking away too much  
class-ness -- though obviously if the class interface to object  
singleton behavior disappears entirely, that won't be an issue.

> As a side note the class Klass lends itself naturally as the mother of all  
> singleton classes - i.e. "pouch == Klass" - a problem with this idea is that  
> we currently have Class \< Module \< Object.

I'm not sure what you mean. If every object's "pouch" is Klass, it  
will get very crowded.... But I think I'm misunderstanding.

David

> **···**
>
> On Mon, 16 May 2005, Christoph wrote:
> 
> --  
> David A. Black  
> dblack@wobblini.net

---

<div class="post-metadata">

**Author:** ![Lionel\_Thiry2](https://avatars.discourse-cdn.com/v4/letter/l/74df32/32.png) [@Lionel\_Thiry2](https://rubytalk.org/u/Lionel_Thiry2)\
**Post date:** [16 May 2005 16:10 UTC](https://rubytalk.org/t/infinite-number-of-singleton-classes/18408/26 "2005-05-16T16:10:31Z")

</div>

Christoph a écrit :

> Ara.T.Howard@noaa.gov schrieb:  
> Actually the behavior is not consistent - assuming the definition  
> ----  
> public # create meta objects  
> def m(height =1)  
> &nbsp;&nbsp;&nbsp;height.zero? ? self : class \<\< self; self end.m(height -1)  
> end  
> ----
> 
> and the natural inheritance assumption, that the class relation
> 
> X \< Y # true, implies  
> X.m \< Y.m # true  
> ---  
> you would expect the following method lookup path for a  
> singleton class of "height" 5  
> ---  
> class A; end  
> class B \< A; end  
> b = B.new
> 
> b.m(5) \<- B.m(4) \< A.m(4) \< Object.m(4) \<  
> Class.m(3) \< Module.m(3) \< Object.m(3) \<  
> Class.m(2) \< Module.m(2) \< Object.m(2) \<  
> Class.m \< Module.m \< Object.m \<  
> Class \< Module \< Object \< Kernel  
> ---
> 
> From a practical point of view this would be rather silly, so Matz bend  
> the rules, and "benevolently ruled" the following to be true  
> ---  
> b.m(5) \< Class.m \< Module.m \< Object.m \<  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Class \< Module \< Object \< Kernel  
> ---
> 
> I personally still prefer honest exception raising over a trickery like  
> this.

What an impressive demonstration.

Let me add more precision to your affirmation:  
b.m(5) \< B.m(4) # =\> nil  
B.m(4) \< A.m(4) # =\> nil  
A.m(4) \< Object.m(4) # =\> nil  
Object.m(4) \< Class.m(3) # =\> nil  
Class.m(3) \< Module.m(3) # =\> nil  
Module.m(3) \< Object.m(3) # =\> nil  
Object.m(3) \< Class.m(2) # =\> nil  
Class.m(2) \< Module.m(2) # =\> nil  
Module.m(2) \< Object.m(2) # =\> nil  
Object.m(2) \< Class.m # =\> true  
Class.m \< Module.m # =\> true  
Module.m \< Object.m # =\> true  
Object.m \< Class # =\> true  
Class \< Module # =\> true  
Module \< Object # =\> true  
Object \< Kernel # =\> true

Then, we have to choose between two things: limit the "height" of singleton  
class, or correct that inheritence model. I'd be for the first one.

> **···**
>
> --  
> Lionel Thiry
> 
> Personal website: [http://users.skynet.be/lthiry/](http://users.skynet.be/lthiry/)

---

<div class="post-metadata">

**Author:** ![Ara.T.Howard6](https://avatars.discourse-cdn.com/v4/letter/a/958977/32.png) [@Ara.T.Howard6](https://rubytalk.org/u/Ara.T.Howard6)\
**Post date:** [16 May 2005 17:40 UTC](https://rubytalk.org/t/infinite-number-of-singleton-classes/18408/27 "2005-05-16T17:40:31Z")

</div>

here we depart. i don't assume this because X's singleton class is just that  
: a singleton (eg. one) class with no relation to that of Y's. i think of as  
in

&nbsp;&nbsp;&nbsp;class Clothes  
&nbsp;&nbsp;&nbsp;end

&nbsp;&nbsp;&nbsp;class Shirts \< Clothes  
&nbsp;&nbsp;&nbsp;end

&nbsp;&nbsp;&nbsp;class Pants \< Clothes  
&nbsp;&nbsp;&nbsp;end

&nbsp;&nbsp;&nbsp;class TShirts \< Shirts  
&nbsp;&nbsp;&nbsp;end

now, obviously, we have something of a hierarchy described in 'is-a' terms:  
TShirt 'is-a' Shirt, etc.

now we thow in a \_\_separate\_\_ hierarchy : Pockets. so

&nbsp;&nbsp;&nbsp;class Pocket  
&nbsp;&nbsp;&nbsp;end

Pockets, obviously, being where classes store their personal (singleton)  
stuff. 😉

now we have

&nbsp;&nbsp;&nbsp;class Clothes  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;class Pocket \< ::Pocket  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;end  
&nbsp;&nbsp;&nbsp;end

&nbsp;&nbsp;&nbsp;class Shirts  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;class Pocket \< ::Pocket  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;end  
&nbsp;&nbsp;&nbsp;end

now this is a 'has-a' relationship: a Pants 'has-a' Pocket class  
(Pants::Pocket) and Shirt 'has-a' Pocket class (Shirt::Pocket). there \_\_is\_\_  
a subtle 'is-a' relationshiop between pocket classes : a Shirt::Pocket 'is-a'  
::Pocket and a Pant::Pocket 'is-a' Pocket. however we do not (necessarily)  
have : Shirt::Pocket 'is-a' Pants::Pocket.

in this case the Pocket class(es) are singleton classes. all classes have one  
that descends from a parent singleton class(es). this is a hierarchy that is  
related to, but separate and parallel from, the hierachy of any classes which  
may themselves have some arbitrary inheritence relationship.

so, for me, it is consistent.

consider the more generic case and it makes much more sense

&nbsp;&nbsp;&nbsp;a =

&nbsp;&nbsp;&nbsp;class \<\< a  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;def foo; 42; end  
&nbsp;&nbsp;&nbsp;end

&nbsp;&nbsp;&nbsp;a2 =

&nbsp;&nbsp;&nbsp;class \<\< a2  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;def bar; 'forty-two'; end  
&nbsp;&nbsp;&nbsp;end

surely the search path for

&nbsp;&nbsp;&nbsp;a.bar

should not look into a2's singleton class for it and, conversely,

&nbsp;&nbsp;&nbsp;a2.foo

should not look into a's singleton class. both methods should raise a  
NoMethodError. why? because there exists no relationship between the  
singleton classes of two instances of a class. in this case the instances are  
of class Array, but remember that ruby classes are just instances of class  
Class so the same holds true.

so the only reason that

&nbsp;&nbsp;&nbsp;class C; end  
&nbsp;&nbsp;&nbsp;class B \< C; end

&nbsp;&nbsp;&nbsp;class \<\< C  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;def foo; 42; end  
&nbsp;&nbsp;&nbsp;end  
&nbsp;&nbsp;&nbsp;class \<\< B  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;def bar; 'forty-two'; end  
&nbsp;&nbsp;&nbsp;end

permits

&nbsp;&nbsp;&nbsp;B.foo

is \_\_not\_\_ because B.singleton\_class \< C.singleton\_class. rather it is  
because the search path for a method is, naturally, up the ancestor list  
hierarchy and, at each step along the way, each class additionally looks  
'sideways' into it's singleton\_class (it's pocket) but not into the  
singleton\_class of any other classes since, by definition, those classes  
belong only to the object that created them - it would be like looking into  
someone else's pockets 😉

cheers.

-a

> **···**
>
> On Tue, 17 May 2005, Christoph wrote:
> 
> > Ara.T.Howard@noaa.gov schrieb:
> > 
> > > > misunderstood something once again?
> > > 
> > > well - sorta 😉
> > > 
> > > i only meant to say that the behaviour is consistent and, although  
> > > there is no  
> > > regular ruby idiom that makes use of it now, there may well be in the  
> > > future.
> > 
> > Actually the behavior is not consistent - assuming the definition  
> > ----  
> > public # create meta objects  
> > def m(height =1)  
> > &nbsp;&nbsp;&nbsp;height.zero? ? self : class \<\< self; self end.m(height -1)  
> > end  
> > ----
> > 
> > and the natural inheritance assumption, that the class relation
> > 
> > X \< Y # true, implies  
> > X.m \< Y.m # true
> 
> # --
> 
> > email :: ara [dot] t [dot] howard [at] noaa [dot] gov  
> > phone :: 303.497.6469  
> > renunciation is not getting rid of the things of this world, but accepting  
> > that they pass away. --aitken roshi
> 
> ===============================================================================

---

<div class="post-metadata">

**Author:** ![Christoph](https://avatars.discourse-cdn.com/v4/letter/c/eb8c5e/32.png) [@Christoph](https://rubytalk.org/u/Christoph)\
**Post date:** [16 May 2005 01:46 UTC](https://rubytalk.org/t/infinite-number-of-singleton-classes/18408/28 "2005-05-16T01:46:14Z")

</div>

David A. Black schrieb:

> I'm just not ready for:
> 
> &nbsp;&nbsp;class \<\< obj; def self.x; end; end
> 
> to throw an error. It just seems like taking away too much  
> class-ness -- though obviously if the class interface to object  
> singleton behavior disappears entirely, that won't be an issue.

I was kind of proposing to throw an error at the next level

class \<\< obj; class \<\< self def self.x; end; end; end

Disallowing the formation of the "singleton singleton class" of  
any type of class including "singleton classes" - this would  
effectively kill Ara's usage example

> > As a side note the class Klass lends itself naturally as the mother of all  
> > singleton classes - i.e. "pouch == Klass" - a problem with this idea is that  
> > we currently have Class \< Module \< Object.
> 
> I'm not sure what you mean. If every object's "pouch" is Klass, it  
> will get very crowded.... But I think I'm misunderstanding.

Singleton classes could be instances of Klass, essentially Klass would be a subclass  
and "singleton class" of Class at the same time. This is similar (kind of the higher order  
version of) of Matju's proposed identification.  
class \<\< Object; self end == Class

/Christoph

---

<div class="post-metadata">

**Author:** ![Anonymous\_Coward](https://avatars.discourse-cdn.com/v4/letter/a/94ad74/32.png) [@Anonymous\_Coward](https://rubytalk.org/u/Anonymous_Coward)\
**Post date:** [16 May 2005 20:01 UTC](https://rubytalk.org/t/infinite-number-of-singleton-classes/18408/29 "2005-05-16T20:01:28Z")

</div>

> > Ara.T.Howard@noaa.gov schrieb:
> > 
> > > > misunderstood something once again?
> > > 
> > > well - sorta 😉
> > > 
> > > i only meant to say that the behaviour is consistent and, although  
> > > there is no  
> > > regular ruby idiom that makes use of it now, there may well be in the  
> > > future.
> > 
> > Actually the behavior is not consistent - assuming the definition  
> > ----  
> > public # create meta objects  
> > def m(height =1)  
> > &nbsp;&nbsp;&nbsp;height.zero? ? self : class \<\< self; self end.m(height -1)  
> > end  
> > ----
> > 
> > and the natural inheritance assumption, that the class relation
> > 
> > X \< Y # true, implies  
> > X.m \< Y.m # true
> 
> here we depart. i don't assume this because X's singleton class is just that  
> : a singleton (eg. one) class with no relation to that of Y's. i think of as  
> in
> 
> &nbsp;&nbsp;class Clothes  
> &nbsp;&nbsp;end
> 
> &nbsp;&nbsp;class Shirts \< Clothes  
> &nbsp;&nbsp;end
> 
> &nbsp;&nbsp;class Pants \< Clothes  
> &nbsp;&nbsp;end
> 
> &nbsp;&nbsp;class TShirts \< Shirts  
> &nbsp;&nbsp;end
> 
> now, obviously, we have something of a hierarchy described in 'is-a' terms:  
> TShirt 'is-a' Shirt, etc.
> 
> now we thow in a \_\_separate\_\_ hierarchy : Pockets. so
> 
> &nbsp;&nbsp;class Pocket  
> &nbsp;&nbsp;end
> 
> Pockets, obviously, being where classes store their personal (singleton)  
> stuff. 😉
> 
> now we have
> 
> &nbsp;&nbsp;class Clothes  
> &nbsp;&nbsp;&nbsp;&nbsp;class Pocket \< ::Pocket  
> &nbsp;&nbsp;&nbsp;&nbsp;end  
> &nbsp;&nbsp;end
> 
> &nbsp;&nbsp;class Shirts  
> &nbsp;&nbsp;&nbsp;&nbsp;class Pocket \< ::Pocket  
> &nbsp;&nbsp;&nbsp;&nbsp;end  
> &nbsp;&nbsp;end
> 
> now this is a 'has-a' relationship: a Pants 'has-a' Pocket class  
> (Pants::Pocket) and Shirt 'has-a' Pocket class (Shirt::Pocket). there \_\_is\_\_  
> a subtle 'is-a' relationshiop between pocket classes : a Shirt::Pocket 'is-a'  
> ::Pocket and a Pant::Pocket 'is-a' Pocket. however we do not (necessarily)  
> have : Shirt::Pocket 'is-a' Pants::Pocket.

No, that would imply Shirt::Pocket \< Pants::Pocket. However, I  
think it is profoundly faulty to imply there is not a significant  
relationship between the two. Both children should share the traits  
of their parent but not those of their siblings.

> in this case the Pocket class(es) are singleton classes. all classes have one  
> that descends from a parent singleton class(es). this is a hierarchy that is  
> related to, but separate and parallel from, the hierachy of any classes which  
> may themselves have some arbitrary inheritence relationship.
> 
> so, for me, it is consistent.
> 
> consider the more generic case and it makes much more sense
> 
> &nbsp;&nbsp;a =
> 
> &nbsp;&nbsp;class \<\< a  
> &nbsp;&nbsp;&nbsp;&nbsp;def foo; 42; end  
> &nbsp;&nbsp;end
> 
> &nbsp;&nbsp;a2 =
> 
> &nbsp;&nbsp;class \<\< a2  
> &nbsp;&nbsp;&nbsp;&nbsp;def bar; 'forty-two'; end  
> &nbsp;&nbsp;end
> 
> surely the search path for
> 
> &nbsp;&nbsp;a.bar
> 
> should not look into a2's singleton class for it and, conversely,
> 
> &nbsp;&nbsp;a2.foo
> 
> should not look into a's singleton class. both methods should raise a  
> NoMethodError. why? because there exists no relationship between the  
> singleton classes of two instances of a class. in this case the instances are  
> of class Array, but remember that ruby classes are just instances of class  
> Class so the same holds true.

Your analysis is correct but the analogy is not quite, er  
analogous. To make it similar, each singleton (or pouch)  
would be a subclass of Pocket here. Therefore, while the  
methods defined in each of them have no relevance to the  
other (siblings' traits are not inherited), they \_should\_  
share the methods from any common ancestors.

So, if child\_one.pouch and child\_two.pouch are subclasses  
of parent.pouch, they should both share any methods in  
parent.pouch but not (necessarily) eachother.

> so the only reason that
> 
> &nbsp;&nbsp;class C; end  
> &nbsp;&nbsp;class B \< C; end
> 
> &nbsp;&nbsp;class \<\< C  
> &nbsp;&nbsp;&nbsp;&nbsp;def foo; 42; end  
> &nbsp;&nbsp;end  
> &nbsp;&nbsp;class \<\< B  
> &nbsp;&nbsp;&nbsp;&nbsp;def bar; 'forty-two'; end  
> &nbsp;&nbsp;end
> 
> permits
> 
> &nbsp;&nbsp;B.foo
> 
> is \_\_not\_\_ because B.singleton\_class \< C.singleton\_class. rather it is  
> because the search path for a method is, naturally, up the ancestor list  
> hierarchy and, at each step along the way, each class additionally looks  
> 'sideways' into it's singleton\_class (it's pocket) but not into the  
> singleton\_class of any other classes since, by definition, those classes  
> belong only to the object that created them - it would be like looking into  
> someone else's pockets 😉

This is certainly true.

> cheers.
> 
> -a

E

> **···**
>
> Le 16/5/2005, "Ara.T.Howard@noaa.gov" \<Ara.T.Howard@noaa.gov\> a écrit:
> 
> > On Tue, 17 May 2005, Christoph wrote:
> 
> --  
> template\<typename duck\>  
> void quack(duck& d) { d.quack(); }

---

<div class="post-metadata">

**Author:** ![Lionel\_Thiry2](https://avatars.discourse-cdn.com/v4/letter/l/74df32/32.png) [@Lionel\_Thiry2](https://rubytalk.org/u/Lionel_Thiry2)\
**Post date:** [16 May 2005 22:25 UTC](https://rubytalk.org/t/infinite-number-of-singleton-classes/18408/30 "2005-05-16T22:25:31Z")

</div>

Ara.T.Howard@noaa.gov a écrit :

> **···**
>
> > On Tue, 17 May 2005, Christoph wrote:
> > 
> > > Ara.T.Howard@noaa.gov schrieb:
> > > 
> > > > > misunderstood something once again?
> > > > 
> > > > well - sorta 😉
> > > > 
> > > > i only meant to say that the behaviour is consistent and, although  
> > > > there is no  
> > > > regular ruby idiom that makes use of it now, there may well be in the  
> > > > future.
> > > 
> > > Actually the behavior is not consistent - assuming the definition  
> > > ----  
> > > public # create meta objects  
> > > def m(height =1)  
> > > &nbsp;&nbsp;&nbsp;height.zero? ? self : class \<\< self; self end.m(height -1)  
> > > end  
> > > ----
> > > 
> > > and the natural inheritance assumption, that the class relation
> > > 
> > > X \< Y # true, implies  
> > > X.m \< Y.m # true
> > 
> > here we depart. i don't assume this because X's singleton class is just  
> > that  
> > : a singleton (eg. one) class with no relation to that of Y's.
> > 
> > [snip]
> > 
> > so the only reason that
> > 
> > &nbsp;&nbsp;class C; end  
> > &nbsp;&nbsp;class B \< C; end
> > 
> > &nbsp;&nbsp;class \<\< C  
> > &nbsp;&nbsp;&nbsp;&nbsp;def foo; 42; end  
> > &nbsp;&nbsp;end  
> > &nbsp;&nbsp;class \<\< B  
> > &nbsp;&nbsp;&nbsp;&nbsp;def bar; 'forty-two'; end  
> > &nbsp;&nbsp;end
> > 
> > permits
> > 
> > &nbsp;&nbsp;B.foo
> > 
> > is \_\_not\_\_ because B.singleton\_class \< C.singleton\_class. rather it is  
> > because the search path for a method is, naturally, up the ancestor list  
> > hierarchy and, at each step along the way, each class additionally looks  
> > 'sideways' into it's singleton\_class (it's pocket) but not into the  
> > singleton\_class of any other classes since, by definition, those classes  
> > belong only to the object that created them - it would be like looking into  
> > someone else's pockets 😉
> 
> [http://www.ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/140562](http://www.ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/140562)
> 
> If you really want ruby2 works the way you described it, I advice you to  
> urgently post an RCR for it.
> 
> --  
> Lionel Thiry
> 
> Personal website: [http://users.skynet.be/lthiry/](http://users.skynet.be/lthiry/)

---

<div class="post-metadata">

**Author:** ![David\_A\_Black3](https://avatars.discourse-cdn.com/v4/letter/d/6a8cbe/32.png) [@David\_A\_Black3](https://rubytalk.org/u/David_A_Black3)\
**Post date:** [16 May 2005 02:02 UTC](https://rubytalk.org/t/infinite-number-of-singleton-classes/18408/31 "2005-05-16T02:02:37Z")

</div>

Hi --

> David A. Black schrieb:
> 
> > I'm just not ready for:
> > 
> > &nbsp;&nbsp;class \<\< obj; def self.x; end; end
> > 
> > to throw an error. It just seems like taking away too much  
> > class-ness -- though obviously if the class interface to object  
> > singleton behavior disappears entirely, that won't be an issue.
> 
> I was kind of proposing to throw an error at the next level
> 
> class \<\< obj; class \<\< self def self.x; end; end; end
> 
> Disallowing the formation of the "singleton singleton class" of  
> any type of class including "singleton classes" - this would  
> effectively kill Ara's usage example

You're three-deep here, though. I thought you meant to disallow  
two-deep (singleton class of a singleton class). (In my example I'm  
assuming that "def self.x" puts x into the singleton class of self,  
which is itself the singleton class of obj.)

> > > As a side note the class Klass lends itself naturally as the mother of all  
> > > singleton classes - i.e. "pouch == Klass" - a problem with this idea is that  
> > > we currently have Class \< Module \< Object.
> > 
> > I'm not sure what you mean. If every object's "pouch" is Klass, it  
> > will get very crowded.... But I think I'm misunderstanding.
> 
> Singleton classes could be instances of Klass, essentially Klass would be a subclass  
> and "singleton class" of Class at the same time. This is similar (kind of the higher order  
> version of) of Matju's proposed identification.
> 
> class \<\< Object; self end == Class

It then becomes a little confusing to call them "classes", since  
they're instances of something other than Class. And it raises the  
whole subclassing Class problem....

David

> **···**
>
> On Mon, 16 May 2005, Christoph wrote:
> 
> --  
> David A. Black  
> dblack@wobblini.net

---

<div class="post-metadata">

**Author:** ![Ara.T.Howard6](https://avatars.discourse-cdn.com/v4/letter/a/958977/32.png) [@Ara.T.Howard6](https://rubytalk.org/u/Ara.T.Howard6)\
**Post date:** [16 May 2005 21:10 UTC](https://rubytalk.org/t/infinite-number-of-singleton-classes/18408/32 "2005-05-16T21:10:31Z")

</div>

> > &nbsp;&nbsp;class Clothes  
> > &nbsp;&nbsp;&nbsp;&nbsp;class Pocket \< ::Pocket  
> > &nbsp;&nbsp;&nbsp;&nbsp;end  
> > &nbsp;&nbsp;end
> > 
> > &nbsp;&nbsp;class Shirts  
> > &nbsp;&nbsp;&nbsp;&nbsp;class Pocket \< ::Pocket  
> > &nbsp;&nbsp;&nbsp;&nbsp;end  
> > &nbsp;&nbsp;end
> > 
> > now this is a 'has-a' relationship: a Pants 'has-a' Pocket class  
> > (Pants::Pocket) and Shirt 'has-a' Pocket class (Shirt::Pocket). there \_\_is\_=
> 
> \_
> 
> > a subtle 'is-a' relationshiop between pocket classes : a Shirt::Pocket 'is-a=
> 
> '
> 
> > ::Pocket and a Pant::Pocket 'is-a' Pocket. however we do not (necessarily)  
> > have : Shirt::Pocket 'is-a' Pants::Pocket.
> 
> No, that would imply Shirt::Pocket \< Pants::Pocket.

how do you figure:

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;harp:~ \> cat a.rb  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;class Pocket; end  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;class Clothes; class Pocket \< ::Pocket; end; end  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;class Shirts; class Pocket \< ::Pocket; end; end

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;p Clothes::Pocket.ancestors  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;p Shirts::Pocket.ancestors

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;harp:~ \> ruby a.rb  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[Clothes::Pocket, Pocket, Object, Kernel]  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[Shirts::Pocket, Pocket, Object, Kernel]

??

> However, I think it is \> profoundly faulty to imply there is not a  
> significant relationship between the two. Both children should share the traits of their parent but not those  
> of their siblings.

but this is exactly the case? in the above both pocket classes share the  
traits of their common parent, Pocket, and neither one shares that of their  
siblings. this is precisely the case of singleton classes - they all descend  
from [Class, Module, Object, Kernel] (the parent classes) and share those  
traits - such as the ability to do 'self.attr :foobar'. i think the mistake  
people are making is thinking that by doing

&nbsp;&nbsp;&nbsp;foo = Foo::new

&nbsp;&nbsp;&nbsp;singleton\_class = class \<\< foo; self; end

is in thinking that singleton\_class 'isa' foo. that is simply not the case.  
rather 'singleton\_class' is owned by foo. in otherwords foo 'has-a'  
singleton\_class and their is no parent child relationship between the two.

i think if the syntax were more like

&nbsp;&nbsp;&nbsp;class Foo  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;singleton\_class = generate\_a\_singleton\_class  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;singleton\_class.attr :bar  
&nbsp;&nbsp;&nbsp;end

vs.

&nbsp;&nbsp;&nbsp;class Foo  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;class \<\< self  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;attr :bar  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;end  
&nbsp;&nbsp;&nbsp;end

this might be more clear. visually the '\<\<' syntax is similar to '\<' in 'A \<  
B' but it doesn't do anything similar - it only generates a special object  
owned by the object calling the '\<\<' operator.

> Your analysis is correct but the analogy is not quite, er  
> analogous. To make it similar, each singleton (or pouch)  
> would be a subclass of Pocket here. Therefore, while the  
> methods defined in each of them have no relevance to the  
> other (siblings' traits are not inherited), they \_should\_  
> share the methods from any common ancestors.

they do. both singletons share the common attributes of their parents:

&nbsp;&nbsp;&nbsp;[Class, Module, Object, Kernel]

again the issue is that

&nbsp;&nbsp;&nbsp;class C  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;class \<\< self  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;this\_is\_a\_child\_of\_Class\_not\_a\_child\_of\_C = self  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;end  
&nbsp;&nbsp;&nbsp;end

so you are right and the analogy is too - all singleton classes share all the  
traits of their common ancestors. it's just that those ancestors don't seem  
to be who people think they are 😉

> So, if child\_one.pouch and child\_two.pouch are subclasses of parent.pouch,  
> they should both share any methods in parent.pouch but not (necessarily)  
> eachother.

you'd be right if that were the relationship between parent/child classes and  
their respective singleton classes - but with singleton\_classes child\_one.pouch  
is a subclass of Pouch and child\_two.pouch is a subclass of Pouch and child\_one  
and child\_two are both children of Parent. check this out closely and you'll  
see it for yourself:

&nbsp;&nbsp;&nbsp;harp:~ \> cat a.rb  
&nbsp;&nbsp;&nbsp;class Class  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;def pouch; class \<\< self; self; end; end  
&nbsp;&nbsp;&nbsp;end  
&nbsp;&nbsp;&nbsp;class Parent  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;p ancestors  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;p pouch.ancestors  
&nbsp;&nbsp;&nbsp;end  
&nbsp;&nbsp;&nbsp;class ChildOne \< Parent  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;p ancestors  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;p pouch.ancestors  
&nbsp;&nbsp;&nbsp;end  
&nbsp;&nbsp;&nbsp;class ChildTwo \< Parent  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;p ancestors  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;p pouch.ancestors  
&nbsp;&nbsp;&nbsp;end

&nbsp;&nbsp;&nbsp;harp:~ \> ruby a.rb

&nbsp;&nbsp;&nbsp;[Parent, Object, Kernel]  
&nbsp;&nbsp;&nbsp;[Class, Module, Object, Kernel]

&nbsp;&nbsp;&nbsp;[ChildOne, Parent, Object, Kernel]  
&nbsp;&nbsp;&nbsp;[Class, Module, Object, Kernel]

&nbsp;&nbsp;&nbsp;[ChildTwo, Parent, Object, Kernel]  
&nbsp;&nbsp;&nbsp;[Class, Module, Object, Kernel]

so the only common ancestors between all the pouches of the above clases are  
[Class, Module, Object, Kernel] and they definitely do inherit all the methods  
from those ancestors.

note that there is relationship \_\_added\_\_ to the pouches by being pouches of  
parent/child classes : all pouches descend from the same Pouch class as in my  
Pocket example above.

for some reason i get the feeling we might be saying the same thing an i'm just  
saying it badly?

cheers.

-a

> **···**
>
> # On Tue, 17 May 2005, ES wrote: --
> 
> > email :: ara [dot] t [dot] howard [at] noaa [dot] gov  
> > phone :: 303.497.6469  
> > renunciation is not getting rid of the things of this world, but accepting  
> > that they pass away. --aitken roshi
> 
> ===============================================================================

---

<div class="post-metadata">

**Author:** ![Ara.T.Howard6](https://avatars.discourse-cdn.com/v4/letter/a/958977/32.png) [@Ara.T.Howard6](https://rubytalk.org/u/Ara.T.Howard6)\
**Post date:** [16 May 2005 23:00 UTC](https://rubytalk.org/t/infinite-number-of-singleton-classes/18408/33 "2005-05-16T23:00:30Z")

</div>

> [http://www.ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/140562](http://www.ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/140562)

yes i saw that.

> If you really want ruby2 works the way you described it, I advice you to  
> urgently post an RCR for it.

no. the new behaviour is fine - i was simply describing how it is now and how  
that relates to the 'infinite levels' issue in that i think it's strange -  
but consistent. believe me - you've no idea how much easier my trait lib  
would have been to write if

&nbsp;&nbsp;&nbsp;child.singleton\_class \< parent.singleton\_class

as it were i had to do this

&nbsp;&nbsp;&nbsp;class \<\< self  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# determine our 'singleton\_super' so we can use it's ancestors  
&nbsp;&nbsp;&nbsp;end

and this is precisely because parent/child meta classes do not fit into the  
same kind of hierarchy as their respective classes. so i will love the new  
behaviour.

i'm going to quit on this now because i feel like i've only confused things.  
sorry if i have.

cheers.

-a

> **···**
>
> # On Tue, 17 May 2005, Lionel Thiry wrote: --
> 
> > email :: ara [dot] t [dot] howard [at] noaa [dot] gov  
> > phone :: 303.497.6469  
> > renunciation is not getting rid of the things of this world, but accepting  
> > that they pass away. --aitken roshi
> 
> ===============================================================================

---

<div class="post-metadata">

**Author:** ![Christoph](https://avatars.discourse-cdn.com/v4/letter/c/eb8c5e/32.png) [@Christoph](https://rubytalk.org/u/Christoph)\
**Post date:** [16 May 2005 03:08 UTC](https://rubytalk.org/t/infinite-number-of-singleton-classes/18408/34 "2005-05-16T03:08:45Z")

</div>

David A. Black schrieb:

> You're three-deep here, though. I thought you meant to disallow  
> two-deep (singleton class of a singleton class). (In my example I'm  
> assuming that "def self.x" puts x into the singleton class of self,  
> which is itself the singleton class of obj.)

Sorry for being my confusing self:🙂

> It then becomes a little confusing to call them "classes", since  
> they're instances of something other than Class. And it raises the  
> whole subclassing Class problem....

Well that's the whole point they (singleton classes) are classes  
but they are also very special kind of classes. For normal objects  
you would xpress this kind of relation ship by sub classing.  
For example, similar to

> **···**
>
> ---  
> class Rodent; end  
> class Mouse \< Rodent; end  
> jerry.instance\_of?(Mouse) # true  
> jerry.instance\_of?(Rodent) # false  
> jerry.kind\_of?(Rodent) # true  
> ---
> 
> it would be
> 
> ---  
> class Klass \< Class; end # we also have Klass == class \<\< Class; self end
> 
> Jerry = class \<\< self; self end  
> Jerry.instance\_of?(Klass) # true  
> Jerry.instance\_of?(Class) # false  
> Jerry.kind\_of?(Class) # true  
> ----
> 
> The sub classing problem isn't all that bad because you could allow  
> sub classing Class exactly once (during the boot up of the object model).  
> Being a subclass and singleton of a class at the same time may sound  
> a bit confusing. On the hand, it also would emphasize the central role  
> of Object, Class (and possibly Klass) and the normal user would never  
> notice the difference.
> 
> /Christoph

---

<div class="post-metadata">

**Author:** ![Anonymous\_Coward](https://avatars.discourse-cdn.com/v4/letter/a/94ad74/32.png) [@Anonymous\_Coward](https://rubytalk.org/u/Anonymous_Coward)\
**Post date:** [16 May 2005 21:32 UTC](https://rubytalk.org/t/infinite-number-of-singleton-classes/18408/35 "2005-05-16T21:32:30Z")

</div>

> > > &nbsp;&nbsp;class Clothes  
> > > &nbsp;&nbsp;&nbsp;&nbsp;class Pocket \< ::Pocket  
> > > &nbsp;&nbsp;&nbsp;&nbsp;end  
> > > &nbsp;&nbsp;end
> > > 
> > > &nbsp;&nbsp;class Shirts  
> > > &nbsp;&nbsp;&nbsp;&nbsp;class Pocket \< ::Pocket  
> > > &nbsp;&nbsp;&nbsp;&nbsp;end  
> > > &nbsp;&nbsp;end
> > > 
> > > now this is a 'has-a' relationship: a Pants 'has-a' Pocket class  
> > > (Pants::Pocket) and Shirt 'has-a' Pocket class (Shirt::Pocket). there \_\_is\_=
> > 
> > \_
> > 
> > > a subtle 'is-a' relationshiop between pocket classes : a Shirt::Pocket 'is-a=
> > 
> > '
> > 
> > > ::Pocket and a Pant::Pocket 'is-a' Pocket. however we do not (necessarily)  
> > > have : Shirt::Pocket 'is-a' Pants::Pocket.
> > 
> > No, that would imply Shirt::Pocket \< Pants::Pocket.
> 
> how do you figure:
> 
> &nbsp;&nbsp;&nbsp;&nbsp;harp:~ \> cat a.rb  
> &nbsp;&nbsp;&nbsp;&nbsp;class Pocket; end  
> &nbsp;&nbsp;&nbsp;&nbsp;class Clothes; class Pocket \< ::Pocket; end; end  
> &nbsp;&nbsp;&nbsp;&nbsp;class Shirts; class Pocket \< ::Pocket; end; end
> 
> &nbsp;&nbsp;&nbsp;&nbsp;p Clothes::Pocket.ancestors  
> &nbsp;&nbsp;&nbsp;&nbsp;p Shirts::Pocket.ancestors
> 
> &nbsp;&nbsp;&nbsp;&nbsp;harp:~ \> ruby a.rb  
> &nbsp;&nbsp;&nbsp;&nbsp;[Clothes::Pocket, Pocket, Object, Kernel]  
> &nbsp;&nbsp;&nbsp;&nbsp;[Shirts::Pocket, Pocket, Object, Kernel]
> 
> ??

Er, I think I was too curt. I meant to say, "No, we do not necessarily  
have Shirt::Pocket is-a Pants::Pocket, \_that\_ would imply Shirt::Pocket  
\< Pants::Pocket. However..." I was agreeing with you on that point but  
disagreeing later 🙂

> > However, I think it is \> profoundly faulty to imply there is not a  
> > significant relationship between the two.  
> > Both children should share the traits of their parent but not those  
> > of their siblings.
> 
> but this is exactly the case? in the above both pocket classes share the  
> traits of their common parent, Pocket, --

Yes, I was merely pointing out that I thought you were perhaps not  
describing the relationship of the siblings accurately.

> -- and neither one shares that of their  
> siblings. this is precisely the case of singleton classes - they all descend  
> from [Class, Module, Object, Kernel] (the parent classes) and share those  
> traits - such as the ability to do 'self.attr :foobar'. i think the mistake  
> people are making is thinking that by doing
> 
> &nbsp;&nbsp;foo = Foo::new
> 
> &nbsp;&nbsp;singleton\_class = class \<\< foo; self; end
> 
> is in thinking that singleton\_class 'isa' foo. that is simply not the case.  
> rather 'singleton\_class' is owned by foo. in otherwords foo 'has-a'  
> singleton\_class and their is no parent child relationship between the two.

Hm, that is a good point, and may well be a common confusion.

> i think if the syntax were more like
> 
> &nbsp;&nbsp;class Foo  
> &nbsp;&nbsp;&nbsp;&nbsp;singleton\_class = generate\_a\_singleton\_class  
> &nbsp;&nbsp;&nbsp;&nbsp;singleton\_class.attr :bar  
> &nbsp;&nbsp;end
> 
> vs.
> 
> &nbsp;&nbsp;class Foo  
> &nbsp;&nbsp;&nbsp;&nbsp;class \<\< self  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;attr :bar  
> &nbsp;&nbsp;&nbsp;&nbsp;end  
> &nbsp;&nbsp;end
> 
> this might be more clear. visually the '\<\<' syntax is similar to '\<' in 'A \<  
> B' but it doesn't do anything similar - it only generates a special object  
> owned by the object calling the '\<\<' operator.
> 
> > Your analysis is correct but the analogy is not quite, er  
> > analogous. To make it similar, each singleton (or pouch)  
> > would be a subclass of Pocket here. Therefore, while the  
> > methods defined in each of them have no relevance to the  
> > other (siblings' traits are not inherited), they \_should\_  
> > share the methods from any common ancestors.
> 
> they do. both singletons share the common attributes of their parents:
> 
> &nbsp;&nbsp;[Class, Module, Object, Kernel]
> 
> again the issue is that
> 
> &nbsp;&nbsp;class C  
> &nbsp;&nbsp;&nbsp;&nbsp;class \<\< self  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;this\_is\_a\_child\_of\_Class\_not\_a\_child\_of\_C = self  
> &nbsp;&nbsp;&nbsp;&nbsp;end  
> &nbsp;&nbsp;end
> 
> so you are right and the analogy is too - all singleton classes share all the  
> traits of their common ancestors. it's just that those ancestors don't seem  
> to be who people think they are 😉
> 
> > So, if child\_one.pouch and child\_two.pouch are subclasses of parent.pouch,  
> > they should both share any methods in parent.pouch but not (necessarily)  
> > eachother.
> 
> you'd be right if that were the relationship between parent/child classes and  
> their respective singleton classes - but with singleton\_classes child\_one.pouch  
> is a subclass of Pouch and child\_two.pouch is a subclass of Pouch and child\_one  
> and child\_two are both children of Parent. check this out closely and you'll  
> see it for yourself:

Agreed! Words fail me again; the 'are' should have been 'were' to  
signal a hypothetical.

> &nbsp;&nbsp;harp:~ \> cat a.rb  
> &nbsp;&nbsp;class Class  
> &nbsp;&nbsp;&nbsp;&nbsp;def pouch; class \<\< self; self; end; end  
> &nbsp;&nbsp;end  
> &nbsp;&nbsp;class Parent  
> &nbsp;&nbsp;&nbsp;&nbsp;p ancestors  
> &nbsp;&nbsp;&nbsp;&nbsp;p pouch.ancestors  
> &nbsp;&nbsp;end  
> &nbsp;&nbsp;class ChildOne \< Parent  
> &nbsp;&nbsp;&nbsp;&nbsp;p ancestors  
> &nbsp;&nbsp;&nbsp;&nbsp;p pouch.ancestors  
> &nbsp;&nbsp;end  
> &nbsp;&nbsp;class ChildTwo \< Parent  
> &nbsp;&nbsp;&nbsp;&nbsp;p ancestors  
> &nbsp;&nbsp;&nbsp;&nbsp;p pouch.ancestors  
> &nbsp;&nbsp;end
> 
> &nbsp;&nbsp;harp:~ \> ruby a.rb
> 
> &nbsp;&nbsp;[Parent, Object, Kernel]  
> &nbsp;&nbsp;[Class, Module, Object, Kernel]
> 
> &nbsp;&nbsp;[ChildOne, Parent, Object, Kernel]  
> &nbsp;&nbsp;[Class, Module, Object, Kernel]
> 
> &nbsp;&nbsp;[ChildTwo, Parent, Object, Kernel]  
> &nbsp;&nbsp;[Class, Module, Object, Kernel]
> 
> so the only common ancestors between all the pouches of the above clases are  
> [Class, Module, Object, Kernel] and they definitely do inherit all the methods  
> from those ancestors.
> 
> note that there is relationship \_\_added\_\_ to the pouches by being pouches of  
> parent/child classes : all pouches descend from the same Pouch class as in my  
> Pocket example above.
> 
> for some reason i get the feeling we might be saying the same thing an i'm just  
> saying it badly?

I are both think we uncommunicating miswell.

Yes, I generally agree with what you are saying, definitely. My  
objection was merely to you (to me) not describing the 'common  
lineage' of the two singletons/pouches correctly, rather than  
the entire explanation. I was not clear about this, sorry.

> cheers.
> 
> -a

E

> **···**
>
> Le 16/5/2005, "Ara.T.Howard@noaa.gov" \<Ara.T.Howard@noaa.gov\> a écrit:
> 
> > On Tue, 17 May 2005, ES wrote:
> 
> --  
> template\<typename duck\>  
> void quack(duck& d) { d.quack(); }

---

<div class="post-metadata">

**Author:** ![Christoph](https://avatars.discourse-cdn.com/v4/letter/c/eb8c5e/32.png) [@Christoph](https://rubytalk.org/u/Christoph)\
**Post date:** [17 May 2005 02:13 UTC](https://rubytalk.org/t/infinite-number-of-singleton-classes/18408/36 "2005-05-17T02:13:11Z")

</div>

Ara.T.Howard@noaa.gov schrieb:

> no. the new behaviour is fine - i was simply describing how it is now and how  
> that relates to the 'infinite levels' issue in that i think it's strange -  
> but consistent. believe me - you've no idea how much easier my trait lib  
> would have been to write if
> 
> &nbsp;&nbsp;child.singleton\_class \< parent.singleton\_class

Well it would be nice if this were true, but it's not - "higher order" singleton class  
behavior changed quite a bit in the past and it so again from 1.82 to todays cvs.  
Lionel point was because Ruby does not seem to have a consistent treatment  
(consitency is always relative to the reades eyes) of these "higher order" singleton  
classes, they should be forbidden in the first place. I ran the following script  
with a standard 1.82, todays cvs.

> **···**
>
> ----  
> puts RUBY\_VERSION  
> public # create meta objects
> 
> def m(height =1)  
> &nbsp;&nbsp;&nbsp;height.zero? ? self : class \<\< self; self end.m(height -1)  
> end
> 
> base = [Object,Module, Class]  
> require 'enumerator'
> 
> (0..11).each\_cons(2) do |a,b|  
> &nbsp;&nbsp;d0,r0 = a.divmod(3)  
> &nbsp;&nbsp;d1,r1 = b.divmod(3)  
> &nbsp;&nbsp;rel = base[r0].m(d0) \> base[r1].m(d1)  
> &nbsp;&nbsp;puts "#{base[r0]}.m(#{d0}) \> #{base[r1]}.m(#{d1}) # #{rel}"  
> end
> 
> class A; end  
> class B \< A; end
> 
> def q(s)  
> &nbsp;&nbsp;puts s \<\< " # #{eval(s)}"  
> end
> 
> puts "\n###","\n"  
> q "B.new.m(5) \< B.m(4)"  
> q "B.m(4) \< A.m(4)"  
> q "A.m(4) \< Object.m(4)"
> 
> puts "\n### print superclass chain","\n"  
> class Class  
> &nbsp;&nbsp;alias succ superclass  
> end
> 
> (1..8).each do |i|  
> &nbsp;&nbsp;puts ((B.new.m(i)..Object).to\_a.join(" : "))  
> end  
> ---
> 
> These were the two outputs
> 
> ---  
> 1.9.0  
> Object.m(0) \> Module.m(0) # true  
> Module.m(0) \> Class.m(0) # true  
> Class.m(0) \> Object.m(1) # true  
> Object.m(1) \> Module.m(1) # true  
> Module.m(1) \> Class.m(1) # true  
> Class.m(1) \> Object.m(2) # false  
> Object.m(2) \> Module.m(2) # false  
> Module.m(2) \> Class.m(2) # false  
> Class.m(2) \> Object.m(3) # true  
> Object.m(3) \> Module.m(3) # false  
> Module.m(3) \> Class.m(3) # false
> 
> ###
> 
> B.new.m(5) \< B.m(4) # true  
> B.m(4) \< A.m(4) # false  
> A.m(4) \< Object.m(4) # false  
> ### print superclass chain
> 
> #\<Class:#\<B:0x101030a0\>\> : B : A : Object  
> Class : Module : Object  
> #\<Class:Class\> : #\<Class:Module\> : #\<Class:Object\> : Class : Module : Object  
> Class : Module : Object  
> #\<Class:Class\> : #\<Class:Module\> : #\<Class:Object\> : Class : Module : Object  
> Class : Module : Object  
> #\<Class:Class\> : #\<Class:Module\> : #\<Class:Object\> : Class : Module : Object  
> Class : Module : Object  
> ---  
> and  
> ---  
> 1.8.2  
> Object.m(0) \> Module.m(0) # true  
> Module.m(0) \> Class.m(0) # true  
> Class.m(0) \> Object.m(1) # true  
> Object.m(1) \> Module.m(1) #  
> Module.m(1) \> Class.m(1) # true  
> Class.m(1) \> Object.m(2) # true  
> Object.m(2) \> Module.m(2) #  
> Module.m(2) \> Class.m(2) #  
> Class.m(2) \> Object.m(3) #  
> Object.m(3) \> Module.m(3) #  
> Module.m(3) \> Class.m(3) #
> 
> ###
> 
> B.new.m(5) \< B.m(4) #  
> B.m(4) \< A.m(4) #  
> A.m(4) \< Object.m(4) #  
> ### print superclass chain
> 
> #\<Class:#\<B:0x2793bc8\>\> : B : A : Object  
> #\<Class:#\<Class:#\<B:0x2793a60\>\>\> : #\<Class:B\> : #\<Class:A\> : #\<Class:Object\> : Class : Module : Object  
> #\<Class:#\<Class:#\<Class:#\<B:0x2793820\>\>\>\> : #\<Class:Class\> : #\<Class:Module\> : #\<Class:Object\> : Class : Module : Object  
> #\<Class:#\<Class:#\<Class:#\<Class:#\<B:0x2793598\>\>\>\>\> : #\<Class:Class\> : #\<Class:Module\> : #\<Class:Object\> : Class : Module : Object  
> #\<Class:#\<Class:#\<Class:#\<Class:#\<Class:#\<B:0x27932c8\>\>\>\>\>\> : #\<Class:Class\> : #\<Class:Module\> : #\<Class:Object\> : Class : Module : Object  
> #\<Class:#\<Class:#\<Class:#\<Class:#\<Class:#\<Class:#\<B:0x2792fb0\>\>\>\>\>\>\> : #\<Class:Class\> : #\<Class:Module\> : #\<Class:Object\> : Class : Module : Object  
> #\<Class:#\<Class:#\<Class:#\<Class:#\<Class:#\<Class:#\<Class:#\<B:0x2792c50\>\>\>\>\>\>\>\> : #\<Class:Class\> : #\<Class:Module\> : #\<Class:Object\> : Class : Module : Object  
> #\<Class:#\<Class:#\<Class:#\<Class:#\<Class:#\<Class:#\<Class:#\<Class:#\<B:0x27928a8\>\>\>\>\>\>\>\>\> : #\<Class:Class\> : #\<Class:Module\> : #\<Class:Object\> : Class : Module : Object  
> ---
> 
> > as it were i had to do this
> > 
> > &nbsp;&nbsp;class \<\< self  
> > &nbsp;&nbsp;&nbsp;&nbsp;# determine our 'singleton\_super' so we can use it's ancestors  
> > &nbsp;&nbsp;end
> > 
> > and this is precisely because parent/child meta classes do not fit into the  
> > same kind of hierarchy as their respective classes. so i will love the new  
> > behaviour.
> > 
> > i'm going to quit on this now because i feel like i've only confused things.  
> > sorry if i have.
> 
> I promise I will quit this too, well after this post:-)
> 
> /Christoph

---

<div class="post-metadata">

**Author:** ![Ara.T.Howard6](https://avatars.discourse-cdn.com/v4/letter/a/958977/32.png) [@Ara.T.Howard6](https://rubytalk.org/u/Ara.T.Howard6)\
**Post date:** [16 May 2005 22:40 UTC](https://rubytalk.org/t/infinite-number-of-singleton-classes/18408/37 "2005-05-16T22:40:31Z")

</div>

> Er, I think I was too curt. I meant to say, "No, we do not necessarily have  
> Shirt::Pocket is-a Pants::Pocket, \_that\_ would imply Shirt::Pocket \<  
> Pants::Pocket. However..." I was agreeing with you on that point but  
> disagreeing later 🙂

ah - i'm on board now.

> > is in thinking that singleton\_class 'isa' foo. that is simply not the case.  
> > rather 'singleton\_class' is owned by foo. in otherwords foo 'has-a'  
> > singleton\_class and their is no parent child relationship between the two.
> 
> Hm, that is a good point, and may well be a common confusion.

it confused me! 😉

> Agreed! Words fail me again; the 'are' should have been 'were' to signal a  
> hypothetical.

o.k. - we're on a roll!

> I are both think we uncommunicating miswell.

who? what? where?

> Yes, I generally agree with what you are saying, definitely. My objection  
> was merely to you (to me) not describing the 'common lineage' of the two  
> singletons/pouches correctly, rather than the entire explanation. I was not  
> clear about this, sorry.

no problem. i had to really struggle to figure all this out for my traits.rb  
lib and am still looking for any opportunity to refine my understanding -  
which was the entire motivation for the long post : i'm trying to make  
\_\_sure\_\_ i know what i think i know.

ciao.

-a

> **···**
>
> # On Tue, 17 May 2005, ES wrote: --
> 
> > email :: ara [dot] t [dot] howard [at] noaa [dot] gov  
> > phone :: 303.497.6469  
> > renunciation is not getting rid of the things of this world, but accepting  
> > that they pass away. --aitken roshi
> 
> ===============================================================================

[Previous page](https://rubytalk.org/t/infinite-number-of-singleton-classes/18408.md?page=1)