# Subclassing Class

**URL:** <https://rubytalk.org/t/subclassing-class/23031>\
**Category:** ruby-talk\
**Created:** [6 December 2005 00:57 UTC](https://rubytalk.org/t/subclassing-class/23031 "2005-12-06T00:57:46Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![John\_Carter](https://avatars.discourse-cdn.com/v4/letter/j/2bfe46/32.png) [@John\_Carter](https://rubytalk.org/u/John_Carter)\
**Post date:** [6 December 2005 00:57 UTC](https://rubytalk.org/t/subclassing-class/23031/1 "2005-12-06T00:57:46Z")

</div>

Ok. This is a wild idea.

I don't like the factory pattern.

We don't need no stinkin Factories. We have the Class object.

All a Factory is really Class.

However, a traditional Factory object can have...  
&nbsp;&nbsp;&nbsp;\* State.  
&nbsp;&nbsp;&nbsp;\* Richer behaviour than the Class class.

Ok, this gets a little hairy so lets get concrete.

class Foo  
end

fo = Foo.new

What is the class of fo? Foo

What is the class of Foo? Class

Now a FooFactory object is just an object with a bit more intelligence  
and state that the traditional Foo class object for making Foo  
instances in a better smarter way.

So the obvious thing to do is instead of making a new class FooFactory  
\< Object, it should inherit from Class.

Well, since Foo is already a Class, we really just want a smarter Class.

ie..

Instead of

class FooFactory  
&nbsp;&nbsp;&nbsp;def initialize( foo\_state)  
&nbsp;&nbsp;&nbsp;&nbsp;@foo\_state = foo\_state  
&nbsp;&nbsp;&nbsp;end

&nbsp;&nbsp;&nbsp;def foo\_fu( bah)  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# Knowledge of Foo making  
&nbsp;&nbsp;&nbsp;end

&nbsp;&nbsp;&nbsp;def create( needs\_fu, stuff)  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Foo.new( foo\_fu( needs\_fu), @foo\_state, stuff)  
&nbsp;&nbsp;&nbsp;end  
end

factory = FooFactory.new( 'foo juice')  
foo = factory.create( 'footile')

We really want

class Foo \< Class  
&nbsp;&nbsp;&nbsp;def initialize( foo\_state)  
&nbsp;&nbsp;&nbsp;&nbsp;@foo\_state = foo\_state  
&nbsp;&nbsp;&nbsp;end

&nbsp;&nbsp;&nbsp;def foo\_fu( bah)  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# Knowledge of Foo making  
&nbsp;&nbsp;&nbsp;end

&nbsp;&nbsp;&nbsp;def new( needs\_fu, stuff)  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;super( foo\_fu( needs\_fu), @foo\_state, stuff)  
&nbsp;&nbsp;&nbsp;end  
end

foo = Foo.new( 'fooless', 'stuffed')

Except ruby doesn't like that  
&nbsp;&nbsp;&nbsp;&nbsp;class Foo \< Class  
bit.

It gets quite grumpy in fact.

Ruby says "can't make subclass of Class (TypeError)"

Rats.

We can however say...

FooClass = Class.new(Class)

Unfortunately we can't then say....

FooClass.new( Object)

Ruby says...  
:in `new': wrong instance allocation (TypeError)

Ahh! I'm just going around in circles fighting Ruby.

We need a way of saying...

class FooClass \< Class  
&nbsp;&nbsp;&nbsp;# Add state and behaviour to Class  
end

And then instead of saying...  
&nbsp;&nbsp;&nbsp;class Foo \< FooParent  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# Add state and behaviour to FooParent  
&nbsp;&nbsp;&nbsp;end  
we need to be able to say...

FooClass Foo \< FooParent  
&nbsp;&nbsp;&nbsp;# Add state and behaviour to FooParent  
end

Aargh! I'm chasing my tail.

Is there anyway, (short of the traditional Factory Pattern) for me to catch my tail?

John Carter Phone : (64)(3) 358 6639  
Tait Electronics Fax : (64)(3) 359 4632  
PO Box 1645 Christchurch Email : [john.carter@tait.co.nz](mailto:john.carter@tait.co.nz)  
New Zealand

Carter's Clarification of Murphy's Law.

"Things only ever go right so that they may go more spectacularly wrong later."

From this principle, all of life and physics may be deduced.

---

<div class="post-metadata">

**Author:** ![Aredridel1](https://avatars.discourse-cdn.com/v4/letter/a/d07c76/32.png) [@Aredridel1](https://rubytalk.org/u/Aredridel1)\
**Post date:** [6 December 2005 01:06 UTC](https://rubytalk.org/t/subclassing-class/23031/2 "2005-12-06T01:06:50Z")

</div>

> We really want
> 
> class Foo \< Class  
> &nbsp;&nbsp;&nbsp;def initialize( foo\_state)  
> &nbsp;&nbsp;&nbsp;&nbsp;@foo\_state = foo\_state  
> &nbsp;&nbsp;&nbsp;end
> 
> &nbsp;&nbsp;&nbsp;def foo\_fu( bah)  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# Knowledge of Foo making  
> &nbsp;&nbsp;&nbsp;end
> 
> &nbsp;&nbsp;&nbsp;def new( needs\_fu, stuff)  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;super( foo\_fu( needs\_fu), @foo\_state, stuff)  
> &nbsp;&nbsp;&nbsp;end  
> end
> 
> foo = Foo.new( 'fooless', 'stuffed')
> 
> Except ruby doesn't like that  
> &nbsp;&nbsp;&nbsp;&nbsp;class Foo \< Class  
> bit.
> 
> It gets quite grumpy in fact.
> 
> Ruby says "can't make subclass of Class (TypeError)"

Yes, there is a way: Singleton classes or "eigenclasses":

class Foo  
&nbsp;&nbsp;def self.new(needs\_fu, stuff) # Could be Foo.new, too, but self keeps  
us warm and DRY.  
&nbsp;&nbsp;&nbsp;&nbsp;super(foo\_fu(needs\_fu), @foo\_state, stuff)  
&nbsp;&nbsp;end  
end

Each Class (and indeed, every other object) has its own private class,  
for just that object alone, the eigenclass. It can have methods added to  
with the def instance.method syntax -- self.new, in this case, or  
Foo.new would work just as well -- and so, Foo.new is different than  
another class's new method. Since it's a "virtual" child class of Class,  
it works as you'd expect with regards to super.

Aria

---

<div class="post-metadata">

**Author:** ![Logan\_Capaldo](https://avatars.discourse-cdn.com/v4/letter/l/7ea924/32.png) [@Logan\_Capaldo](https://rubytalk.org/u/Logan_Capaldo)\
**Post date:** [6 December 2005 01:07 UTC](https://rubytalk.org/t/subclassing-class/23031/3 "2005-12-06T01:07:36Z")

</div>

Why are you trying so hard?

class Foo  
&nbsp;&nbsp;&nbsp;&nbsp;# state and behavior for Foo the Class  
&nbsp;&nbsp;&nbsp;&nbsp;# using class instance variables and singleton methods  
&nbsp;&nbsp;&nbsp;# eg:  
&nbsp;&nbsp;&nbsp;@foo\_state = foo\_state # this works believe it or not  
&nbsp;&nbsp;&nbsp;# etc.  
@old\_new = method(:new)  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;def self.new(needs\_fi, stuff)  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;@old\_new.call(foo\_fu(needs\_fu, @foo\_state, stuff)  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;end  
end

What does subclassing class get you over this approach? Your class can be your factory (in ruby anyway).

> **···**
>
> On Dec 5, 2005, at 7:57 PM, John Carter wrote:
> 
> > Ok. This is a wild idea.
> > 
> > I don't like the factory pattern.
> > 
> > We don't need no stinkin Factories. We have the Class object.
> > 
> > All a Factory is really Class.
> > 
> > However, a traditional Factory object can have...  
> > &nbsp;&nbsp;\* State.  
> > &nbsp;&nbsp;\* Richer behaviour than the Class class.
> > 
> > Ok, this gets a little hairy so lets get concrete.
> > 
> > class Foo  
> > end
> > 
> > fo = Foo.new
> > 
> > What is the class of fo? Foo
> > 
> > What is the class of Foo? Class
> > 
> > Now a FooFactory object is just an object with a bit more intelligence  
> > and state that the traditional Foo class object for making Foo  
> > instances in a better smarter way.
> > 
> > So the obvious thing to do is instead of making a new class FooFactory  
> > \< Object, it should inherit from Class.
> > 
> > Well, since Foo is already a Class, we really just want a smarter Class.
> > 
> > ie..
> > 
> > Instead of
> > 
> > class FooFactory  
> > &nbsp;&nbsp;def initialize( foo\_state)  
> > &nbsp;&nbsp;&nbsp;@foo\_state = foo\_state  
> > &nbsp;&nbsp;end
> > 
> > &nbsp;&nbsp;def foo\_fu( bah)  
> > &nbsp;&nbsp;&nbsp;&nbsp;# Knowledge of Foo making  
> > &nbsp;&nbsp;end
> > 
> > &nbsp;&nbsp;def create( needs\_fu, stuff)  
> > &nbsp;&nbsp;&nbsp;&nbsp;Foo.new( foo\_fu( needs\_fu), @foo\_state, stuff)  
> > &nbsp;&nbsp;end  
> > end
> > 
> > factory = FooFactory.new( 'foo juice')  
> > foo = factory.create( 'footile')
> > 
> > We really want
> > 
> > class Foo \< Class  
> > &nbsp;&nbsp;def initialize( foo\_state)  
> > &nbsp;&nbsp;&nbsp;@foo\_state = foo\_state  
> > &nbsp;&nbsp;end
> > 
> > &nbsp;&nbsp;def foo\_fu( bah)  
> > &nbsp;&nbsp;&nbsp;&nbsp;# Knowledge of Foo making  
> > &nbsp;&nbsp;end
> > 
> > &nbsp;&nbsp;def new( needs\_fu, stuff)  
> > &nbsp;&nbsp;&nbsp;&nbsp;super( foo\_fu( needs\_fu), @foo\_state, stuff)  
> > &nbsp;&nbsp;end  
> > end
> > 
> > foo = Foo.new( 'fooless', 'stuffed')
> > 
> > Except ruby doesn't like that  
> > &nbsp;&nbsp;&nbsp;class Foo \< Class  
> > bit.
> > 
> > It gets quite grumpy in fact.
> > 
> > Ruby says "can't make subclass of Class (TypeError)"
> > 
> > Rats.
> > 
> > We can however say...
> > 
> > FooClass = Class.new(Class)
> > 
> > Unfortunately we can't then say....
> > 
> > FooClass.new( Object)
> > 
> > Ruby says...  
> > :in `new': wrong instance allocation (TypeError)
> > 
> > Ahh! I'm just going around in circles fighting Ruby.
> > 
> > We need a way of saying...
> > 
> > class FooClass \< Class  
> > &nbsp;&nbsp;# Add state and behaviour to Class  
> > end
> > 
> > And then instead of saying...  
> > &nbsp;&nbsp;class Foo \< FooParent  
> > &nbsp;&nbsp;&nbsp;&nbsp;# Add state and behaviour to FooParent  
> > &nbsp;&nbsp;end  
> > we need to be able to say...
> > 
> > FooClass Foo \< FooParent  
> > &nbsp;&nbsp;# Add state and behaviour to FooParent  
> > end
> > 
> > Aargh! I'm chasing my tail.
> > 
> > Is there anyway, (short of the traditional Factory Pattern) for me to catch my tail?
> > 
> > John Carter Phone : (64)(3) 358 6639  
> > Tait Electronics Fax : (64)(3) 359 4632  
> > PO Box 1645 Christchurch Email : john.carter@tait.co.nz  
> > New Zealand
> > 
> > Carter's Clarification of Murphy's Law.
> > 
> > "Things only ever go right so that they may go more spectacularly wrong later."
> > 
> > From this principle, all of life and physics may be deduced.

---

<div class="post-metadata">

**Author:** ![gabriele\_renzi3](https://avatars.discourse-cdn.com/v4/letter/g/7bcc69/32.png) [@gabriele\_renzi3](https://rubytalk.org/u/gabriele_renzi3)\
**Post date:** [6 December 2005 02:03 UTC](https://rubytalk.org/t/subclassing-class/23031/4 "2005-12-06T02:03:53Z")

</div>

John Carter ha scritto:

> Ok. This is a wild idea.
> 
> I don't like the factory pattern.
> 
> We don't need no stinkin Factories. We have the Class object.

given that people already told you about overriding Class#new, I won't replicate.  
But I wonder what is the problem you're tying to solve, if you just want to add state and behaviour to an object, maybe you could just include/extend a module?

---

<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:** [6 December 2005 01:24 UTC](https://rubytalk.org/t/subclassing-class/23031/5 "2005-12-06T01:24:27Z")

</div>

Hi --

> Each Class (and indeed, every other object) has its own private class,  
> for just that object alone, the eigenclass. It can have methods added to

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;^^^^^^^^^^

Is there any chance of stemming the tide of nicknames and coined synonyms  
for singleton classes? Or may I at least put in a plea for flagging them  
as nicknames and coinages? I know there's a kind of ongoing discussion  
about what the best eventual official name might be, if "singleton class"  
is ever replaced, but I think that having a lot of unofficial/unflagged  
names in circulation is potentially very confusing and therefore probably  
not an ideal interim measure.

David

> **···**
>
> On Tue, 6 Dec 2005, Aredridel wrote:  
> \_\_  
> David A. Black  
> dblack@wobblini.net
> 
> "Ruby for Rails", forthcoming from Manning Publications, April 2006!

---

<div class="post-metadata">

**Author:** ![7rans](https://avatars.discourse-cdn.com/v4/letter/7/a8b319/32.png) [@7rans](https://rubytalk.org/u/7rans)\
**Post date:** [6 December 2005 01:37 UTC](https://rubytalk.org/t/subclassing-class/23031/6 "2005-12-06T01:37:34Z")

</div>

> Yes, there is a way: Singleton classes or "eigenclasses".

In this context it is generally called the metaclass. But I'm really  
digging this new "adhoc". As in, "He completely rewrote the method  
\_adhoc\_."

BTW, factories come into play when the class of the object instantiated  
is unknown. I don't see that. It looks like you (John) are talking more  
about alternate instantation signitures --but maybe I've overlooked  
something in what you said. Nonetheless, it is true that a class method  
(class methods are adhoc) can be used in either case.

T.

---

<div class="post-metadata">

**Author:** ![John\_Carter](https://avatars.discourse-cdn.com/v4/letter/j/2bfe46/32.png) [@John\_Carter](https://rubytalk.org/u/John_Carter)\
**Post date:** [6 December 2005 02:41 UTC](https://rubytalk.org/t/subclassing-class/23031/7 "2005-12-06T02:41:26Z")

</div>

Add state and polymorphic behaviour, not to the object, but the object's class. And that is where the wheels fall off.

@@variables give classes state.

ClassName.method\_name functions given classes behaviour.

But it is all static, no polymorphism.

(Perhaps I should have called it the factory method pattern. When I tried to find a definitive answer on that I find I'm certainly not alone in stirring that particular pot of confusion...)

John Carter Phone : (64)(3) 358 6639  
Tait Electronics Fax : (64)(3) 359 4632  
PO Box 1645 Christchurch Email : john.carter@tait.co.nz  
New Zealand

Carter's Clarification of Murphy's Law.

"Things only ever go right so that they may go more spectacularly wrong later."

From this principle, all of life and physics may be deduced.

> **···**
>
> On Tue, 6 Dec 2005, gabriele renzi wrote:
> 
> > John Carter ha scritto:
> > 
> > > Ok. This is a wild idea.
> > > 
> > > I don't like the factory pattern.
> > > 
> > > We don't need no stinkin Factories. We have the Class object.
> > 
> > But I wonder what is the problem you're tying to solve, if you just want to add state and behaviour to an object, maybe you could just include/extend a module?

---

<div class="post-metadata">

**Author:** ![John\_Carter](https://avatars.discourse-cdn.com/v4/letter/j/2bfe46/32.png) [@John\_Carter](https://rubytalk.org/u/John_Carter)\
**Post date:** [6 December 2005 02:54 UTC](https://rubytalk.org/t/subclassing-class/23031/8 "2005-12-06T02:54:47Z")

</div>

Err. Right.

On to the next step. Let's rename Foo to AbstractFoo

Now I wanted  
&nbsp;&nbsp;&nbsp;class AbstractFoo \< Class  
&nbsp;&nbsp;&nbsp;end

and you have given me that. But that was merely the first step in my agenda.

I actually also want....  
&nbsp;&nbsp;&nbsp;class ConcreteFooClass \< AbstractFooClass  
&nbsp;&nbsp;&nbsp;end

&nbsp;&nbsp;&nbsp;class OtherConcreteFooClass \< AbstractFooClass  
&nbsp;&nbsp;&nbsp;end  
that polymorphically inherits behaviour from AbstractFooClass.

I'm starting to really hate the Builder, Factory, AbstractFactory, FactoryMethod names. They are not explicit enough to distinguish which is what from the name, and the web seems to pretty confused on the subject as well. Anyhoo, factory method pattern is what trying to do.

John Carter Phone : (64)(3) 358 6639  
Tait Electronics Fax : (64)(3) 359 4632  
PO Box 1645 Christchurch Email : john.carter@tait.co.nz  
New Zealand

Carter's Clarification of Murphy's Law.

"Things only ever go right so that they may go more spectacularly wrong later."

From this principle, all of life and physics may be deduced.

> **···**
>
> On Tue, 6 Dec 2005, Aredridel wrote:
> 
> > class Foo  
> > def self.new(needs\_fu, stuff) # Could be Foo.new, too, but self keeps  
> > us warm and DRY.  
> > &nbsp;&nbsp;&nbsp;super(foo\_fu(needs\_fu), @foo\_state, stuff)  
> > end  
> > end
> 
> > Each Class (and indeed, every other object) has its own private class,  
> > for just that object alone, the eigenclass. It can have methods added to  
> > with the def instance.method syntax -- self.new, in this case, or  
> > Foo.new would work just as well -- and so, Foo.new is different than  
> > another class's new method. Since it's a "virtual" child class of Class,  
> > it works as you'd expect with regards to super.

---

<div class="post-metadata">

**Author:** ![John\_Carter](https://avatars.discourse-cdn.com/v4/letter/j/2bfe46/32.png) [@John\_Carter](https://rubytalk.org/u/John_Carter)\
**Post date:** [6 December 2005 03:08 UTC](https://rubytalk.org/t/subclassing-class/23031/9 "2005-12-06T03:08:19Z")

</div>

Hmm. It's perfectly standard mathematical terminology for an operator A, if you can find a limited subset of items e\_i such that A operating on item e\_i results in the same item e\_i (upto a scalar factor), then the e\_i are called an eigenstate of the operator A and the scalar factor is the eigenvalue.

This usage of the term "eigen" is far far wider than ruby and far far older.

If this usage maps in some fairly clear manner onto singleton classes then clearly the term singleton class should be dropped in favour of eigenclass.

The question then is "Is there an operation which leaves the singleton classes, and only the singleton classes, unaltered (except perhaps in some trivial fashion)?"

John Carter Phone : (64)(3) 358 6639  
Tait Electronics Fax : (64)(3) 359 4632  
PO Box 1645 Christchurch Email : john.carter@tait.co.nz  
New Zealand

Carter's Clarification of Murphy's Law.

"Things only ever go right so that they may go more spectacularly wrong later."

From this principle, all of life and physics may be deduced.

> **···**
>
> On Tue, 6 Dec 2005, David A. Black wrote:
> 
> > On Tue, 6 Dec 2005, Aredridel wrote:
> > 
> > > Each Class (and indeed, every other object) has its own private class,  
> > > for just that object alone, the eigenclass. It can have methods added to
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;^^^^^^^^^^
> > 
> > Is there any chance of stemming the tide of nicknames and coined synonyms  
> > for singleton classes?

---

<div class="post-metadata">

**Author:** ![Wayne\_Vucenic1](https://avatars.discourse-cdn.com/v4/letter/w/f17d59/32.png) [@Wayne\_Vucenic1](https://rubytalk.org/u/Wayne_Vucenic1)\
**Post date:** [6 December 2005 03:58 UTC](https://rubytalk.org/t/subclassing-class/23031/10 "2005-12-06T03:58:37Z")

</div>

Hi John,

> I'm starting to really hate the Builder, Factory, AbstractFactory,  
> FactoryMethod names. They are not explicit enough to distinguish which is  
> what from the name

I agree with you. I once heard Eric Evans (author of the \_best\_  
technical book I've ever read, "Domain Driven Design") remark that he  
thought the GoF "Factory Method" should be called "Polymorphic  
Factory" and "Abstract Factory" should be "Family Factory". Eric's  
names make a lot of sense to me.

Wayne Vucenic  
No Bugs Software  
"Ruby and C++ Agile Contract Programming in Silicon Valley"

---

<div class="post-metadata">

**Author:** ![Pit](https://avatars.discourse-cdn.com/v4/letter/p/f14d63/32.png) [@Pit](https://rubytalk.org/u/Pit)\
**Post date:** [6 December 2005 08:30 UTC](https://rubytalk.org/t/subclassing-class/23031/11 "2005-12-06T08:30:43Z")

</div>

John Carter schrieb:

> On to the next step. Let's rename Foo to AbstractFoo
> 
> Now I wanted  
> &nbsp;&nbsp;class AbstractFoo \< Class  
> &nbsp;&nbsp;end
> 
> and you have given me that. But that was merely the first step in my agenda.
> 
> I actually also want....  
> &nbsp;&nbsp;class ConcreteFooClass \< AbstractFooClass  
> &nbsp;&nbsp;end
> 
> &nbsp;&nbsp;class OtherConcreteFooClass \< AbstractFooClass  
> &nbsp;&nbsp;end  
> that polymorphically inherits behaviour from AbstractFooClass.

John, I'm not sure what you really need, but I think that the singleton class approach that others have suggested gives you the desired behaviour:

&nbsp;&nbsp;&nbsp;class Foo  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;def self.new fu, stuff  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;super "#{fu} and #{stuff}"  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;end  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;def initialize things  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;puts "new Foo with #{things}"  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;end  
&nbsp;&nbsp;&nbsp;end

&nbsp;&nbsp;&nbsp;Foo.new "abstract fu", "abstract stuff"  
&nbsp;&nbsp;&nbsp;# =\> new Foo with abstract fu and abstract stuff

&nbsp;&nbsp;&nbsp;class ConcreteFoo \< Foo  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;def self.new fu  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;super fu, "concrete stuff"  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;end  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;def initialize things  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;print "ConcreteFoo: "  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;super  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;end  
&nbsp;&nbsp;&nbsp;end

&nbsp;&nbsp;&nbsp;ConcreteFoo.new "concrete fu"  
&nbsp;&nbsp;&nbsp;# =\> ConcreteFoo: new Foo with concrete fu and concrete stuff

The class ConcreteFoo inherits behaviour from the class Foo and ConcreteFoo's singleton class inherits from Foo's singleton class.

I don't know whether this still works in Ruby 1.9, though.

Regards,  
Pit

---

<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:** [6 December 2005 03:36 UTC](https://rubytalk.org/t/subclassing-class/23031/12 "2005-12-06T03:36:21Z")

</div>

Hi --

> \>  
> \>\> Each Class (and indeed, every other object) has its own private class,  
> \>\> for just that object alone, the eigenclass. It can have methods added to  
> \> ^^^^^^^^^^  
> \>  
> \> Is there any chance of stemming the tide of nicknames and coined synonyms  
> \> for singleton classes?
> 
> Hmm. It's perfectly standard mathematical terminology for an operator A,  
> if you can find a limited subset of items e\_i such that A operating on  
> item e\_i results in the same item e\_i (upto a scalar factor), then  
> the e\_i are called an eigenstate of the operator A and the scalar factor  
> is the eigenvalue.
> 
> This usage of the term "eigen" is far far wider than ruby and far far  
> older.

So are thousands of other usages of "eigen" 🙂 But I'm not arguing for  
or against 'eigenclass'. I'm just suggesting that we not enter an era --  
or, rather that we leave the era we appear to have entered -- of using a  
variety of unofficial names for singleton classes as if they were the  
official name.

> \> If this usage maps in some fairly clear manner onto singleton classes then  
> clearly the term singleton class should be dropped in favour of  
> eigenclass.
> 
> The question then is "Is there an operation which leaves the singleton  
> classes, and only the singleton classes, unaltered (except perhaps in some  
> trivial fashion)?"

"Eigen" is actually a much more common and adaptable term than that.  
It's basically German for "own", and appears all over the place in  
compounds and as a prefix (Eigentum is property (stuff you own),  
Eigenschaft is a property (in the sense of a characteristic), etc.).

No particular antecedent coinage has a claim on Ruby's loyalty. If it's a  
good replacement for "singleton class", it's because of what "eigen" +  
"class" suggests in its own right.

David

> **···**
>
> On Tue, 6 Dec 2005, John Carter wrote:
> 
> > On Tue, 6 Dec 2005, David A. Black wrote:  
> > \> On Tue, 6 Dec 2005, Aredridel wrote:
> 
> \_\_  
> David A. Black  
> dblack@wobblini.net
> 
> "Ruby for Rails", forthcoming from Manning Publications, April 2006!

---

<div class="post-metadata">

**Author:** ![Ross\_Bamford2](https://avatars.discourse-cdn.com/v4/letter/r/e47774/32.png) [@Ross\_Bamford2](https://rubytalk.org/u/Ross_Bamford2)\
**Post date:** [6 December 2005 10:17 UTC](https://rubytalk.org/t/subclassing-class/23031/13 "2005-12-06T10:17:33Z")

</div>

It seems to (as of a few days ago at least):

&nbsp;&nbsp;&nbsp;[rosco@jukebox ruby]$ ruby oneninetest.rb  
&nbsp;&nbsp;&nbsp;new Foo with abstract fu and abstract stuff  
&nbsp;&nbsp;&nbsp;ConcreteFoo: new Foo with concrete fu and concrete stuff

&nbsp;&nbsp;&nbsp;[rosco@jukebox ruby]$ ruby9 oneninetest.rb  
&nbsp;&nbsp;&nbsp;new Foo with abstract fu and abstract stuff  
&nbsp;&nbsp;&nbsp;ConcreteFoo: new Foo with concrete fu and concrete stuff

> **···**
>
> On Tue, 06 Dec 2005 08:30:43 -0000, Pit Capitain \<pit@capitain.de\> wrote:
> 
> > The class ConcreteFoo inherits behaviour from the class Foo and ConcreteFoo's singleton class inherits from Foo's singleton class.
> > 
> > I don't know whether this still works in Ruby 1.9, though.
> 
> --  
> Ross Bamford - rosco@roscopeco.remove.co.uk  
> "\e[1;31mL"

---

<div class="post-metadata">

**Author:** ![Martin\_DeMello1](https://avatars.discourse-cdn.com/v4/letter/m/3be4f8/32.png) [@Martin\_DeMello1](https://rubytalk.org/u/Martin_DeMello1)\
**Post date:** [6 December 2005 14:42 UTC](https://rubytalk.org/t/subclassing-class/23031/14 "2005-12-06T14:42:34Z")

</div>

The mathematical usage draws on the German word for "own", as does  
"eigenclass". It's a lot less ambiguous a term than "singleton class",  
and the fact that it's a pleasing and apt term is indicated by the  
number of rubyists who implicitly vote by using it. I don't think any  
other term has caught on as well since people started expressing  
dissatisfaction with the ambiguous nature of "singleton class" and  
"metaclass".

martin

> **···**
>
> John Carter \<john.carter@tait.co.nz\> wrote:
> 
> > Hmm. It's perfectly standard mathematical terminology for an operator A,  
> > if you can find a limited subset of items e\_i such that A operating on  
> > item e\_i results in the same item e\_i (upto a scalar factor), then  
> > the e\_i are called an eigenstate of the operator A and the scalar factor  
> > is the eigenvalue.
> > 
> > This usage of the term "eigen" is far far wider than ruby and far far  
> > older.
> > 
> > If this usage maps in some fairly clear manner onto singleton classes then  
> > clearly the term singleton class should be dropped in favour of  
> > eigenclass.
> > 
> > The question then is "Is there an operation which leaves the singleton  
> > classes, and only the singleton classes, unaltered (except perhaps in some  
> > trivial fashion)?"

---

<div class="post-metadata">

**Author:** ![Ross\_Bamford2](https://avatars.discourse-cdn.com/v4/letter/r/e47774/32.png) [@Ross\_Bamford2](https://rubytalk.org/u/Ross_Bamford2)\
**Post date:** [6 December 2005 10:07 UTC](https://rubytalk.org/t/subclassing-class/23031/15 "2005-12-06T10:07:34Z")

</div>

Absolutely. Which I would suggest is 'very little', if only because there are so many and varied (and often technical) uses already for 'eigen'. 'Singleton class' has a kind-of-correctness about it I think which puts the newbie on the right track. I'm not advocating sticking with it, but it stripped away some mystique for me early on, and that kind of hint is important...

Also strongly agree with your observations about the the current situation - it was most confusing when I started out, and I know that a few others find the changeable terminology confusing. I believe that one official bad name has to be better than N unofficial ones regardless of quality or correctness.

> **···**
>
> On Tue, 06 Dec 2005 03:36:21 -0000, David A. Black \<dblack@wobblini.net\> wrote:
> 
> > No particular antecedent coinage has a claim on Ruby's loyalty. If it's a  
> > good replacement for "singleton class", it's because of what "eigen" +  
> > "class" suggests in its own right.
> 
> --  
> Ross Bamford - rosco@roscopeco.remove.co.uk  
> "\e[1;31mL"

---

<div class="post-metadata">

**Author:** ![Pit](https://avatars.discourse-cdn.com/v4/letter/p/f14d63/32.png) [@Pit](https://rubytalk.org/u/Pit)\
**Post date:** [6 December 2005 10:53 UTC](https://rubytalk.org/t/subclassing-class/23031/16 "2005-12-06T10:53:27Z")

</div>

Ross Bamford schrieb:

> **···**
>
> > On Tue, 06 Dec 2005 08:30:43 -0000, Pit Capitain \<pit@capitain.de\> wrote:
> > 
> > > The class ConcreteFoo inherits behaviour from the class Foo and ConcreteFoo's singleton class inherits from Foo's singleton class.
> > > 
> > > I don't know whether this still works in Ruby 1.9, though.
> > 
> > It seems to (as of a few days ago at least):
> > 
> > &nbsp;&nbsp;[rosco@jukebox ruby]$ ruby oneninetest.rb  
> > &nbsp;&nbsp;new Foo with abstract fu and abstract stuff  
> > &nbsp;&nbsp;ConcreteFoo: new Foo with concrete fu and concrete stuff
> > 
> > &nbsp;&nbsp;[rosco@jukebox ruby]$ ruby9 oneninetest.rb  
> > &nbsp;&nbsp;new Foo with abstract fu and abstract stuff  
> > &nbsp;&nbsp;ConcreteFoo: new Foo with concrete fu and concrete stuff
> 
> Thanks for the info, Ross. I remember vaguely that something about the inheritance of classes' singleton classes should change in Ruby 2, but I'm not sure.
> 
> Regards,  
> Pit

---

<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:** [6 December 2005 15:11 UTC](https://rubytalk.org/t/subclassing-class/23031/17 "2005-12-06T15:11:15Z")

</div>

Hi --

> \> Hmm. It's perfectly standard mathematical terminology for an operator A,  
> \> if you can find a limited subset of items e\_i such that A operating on  
> \> item e\_i results in the same item e\_i (upto a scalar factor), then  
> \> the e\_i are called an eigenstate of the operator A and the scalar factor  
> \> is the eigenvalue.  
> \>  
> \> This usage of the term "eigen" is far far wider than ruby and far far  
> \> older.  
> \>  
> \> If this usage maps in some fairly clear manner onto singleton classes then  
> \> clearly the term singleton class should be dropped in favour of  
> \> eigenclass.  
> \>  
> \> The question then is "Is there an operation which leaves the singleton  
> \> classes, and only the singleton classes, unaltered (except perhaps in some  
> \> trivial fashion)?"
> 
> The mathematical usage draws on the German word for "own", as does  
> "eigenclass". It's a lot less ambiguous a term than "singleton class",  
> and the fact that it's a pleasing and apt term is indicated by the  
> number of rubyists who implicitly vote by using it.

A lot of the usage I've seen is from newcomers who see the term used by  
non-newcomers and have no reason (because the situation is not explained  
to them) to believe that it's anything but the standard, official term.

> I don't think any other term has caught on as well since people started  
> expressing dissatisfaction with the ambiguous nature of "singleton  
> class" and "metaclass".

That may be due to restraint on the part of people who prefer other terms  
than "eigenclass" but don't think there should be a  
"vote"-by-pre-emptive-usage contest in this area. I suppose I could start  
telling people that there's a thing called the "own class" in Ruby (a term  
I've suggested) but I've chosen not to.

David

> **···**
>
> On Tue, 6 Dec 2005, Martin DeMello wrote:
> 
> > John Carter \<john.carter@tait.co.nz\> wrote:
> 
> \_\_  
> David A. Black  
> dblack@wobblini.net
> 
> "Ruby for Rails", forthcoming from Manning Publications, April 2006!

---

<div class="post-metadata">

**Author:** ![Gary\_Wright](https://avatars.discourse-cdn.com/v4/letter/g/58956e/32.png) [@Gary\_Wright](https://rubytalk.org/u/Gary_Wright)\
**Post date:** [6 December 2005 15:57 UTC](https://rubytalk.org/t/subclassing-class/23031/18 "2005-12-06T15:57:49Z")

</div>

Isn't that pretty much how all new jargon comes into being, by being used?  
Even in academic papers you'll see words and phrases coined without a vote  
and if the semantics appeal to the community they will be referenced and  
reused in another paper until they become part of the standard nomenclature.

I do understand that new terms can be confusing and, unlike a refereed paper,  
most posters don't have footnotes to define all their terms, but new terms  
will continue to emerge (e.g., Ajax) spontaneously.

The Ruby community is very fortunate to have Matz to sift through all the  
suggestions, RCRs, code, and discussion and provide a certain amount of  
guidance, but that doesn't preclude other sources of inspiration (I hope).

The big elephant in the room seems to be Matz comments that the semantics  
of a meta/singleton/eigen class might be implemented via some mechanism  
other than a class, which would certainly stir the pot a bit.

> **···**
>
> On Dec 6, 2005, at 10:11 AM, David A. Black wrote:
> 
> > That may be due to restraint on the part of people who prefer other terms  
> > than "eigenclass" but don't think there should be a  
> > "vote"-by-pre-emptive-usage contest in this area.

---

<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:** [6 December 2005 16:19 UTC](https://rubytalk.org/t/subclassing-class/23031/19 "2005-12-06T16:19:08Z")

</div>

Hi --

> \> That may be due to restraint on the part of people who prefer other  
> \> terms  
> \> than "eigenclass" but don't think there should be a  
> \> "vote"-by-pre-emptive-usage contest in this area.
> 
> Isn't that pretty much how all new jargon comes into being, by being  
> used? Even in academic papers you'll see words and phrases coined  
> without a vote and if the semantics appeal to the community they will be  
> referenced and reused in another paper until they become part of the  
> standard nomenclature.

I know -- I've done it myself. I've never hesitated to use neologisms in  
my own academic work, and if people find them helpful, they can use them.  
If not, they're just something I came up with to help explain some  
concept.

This is different. First of all, Ruby is a work by Matz, not any of us.  
But, granting that single authorship is not really the whole story here,  
there's no vacuum for "eigen/virtual/meta/single/adhoc"-class to fill  
anyway. There's some fragility in the existing terms, but they do exist,  
and the fragility is being examined carefully by Matz with community  
input. What is the benefit of short-circuiting that process?

And let's say your model does apply. That means -- as in common speech  
and academic discourse -- that different groups of people will use  
different jargon for the same things. We'll have the eigenclass people,  
the metaclass people, and so on. And newcomers will have to learn about  
all of them, so that they can talk to everyone.

I think, among other things, that there's a limit to how tolerant people  
are going to be of being expected to wallow in all this meta-meta-culture.  
It's certainly not what attracted me to Ruby.

> I do understand that new terms can be confusing and, unlike a refereed  
> paper, most posters don't have footnotes to define all their terms, but  
> new terms will continue to emerge (e.g., Ajax) spontaneously.
> 
> The Ruby community is very fortunate to have Matz to sift through all  
> the suggestions, RCRs, code, and discussion and provide a certain amount  
> of guidance, but that doesn't preclude other sources of inspiration (I  
> hope).

How about channeling these inspirations \*through\* the RCRs and  
discussions? I just can't see how throwing arbitrarily many home-made  
synonyms for language-level constructs at newcomers can be of the  
slightest benefit. In the short term I suppose it's exhilerating and  
makes people feel creative and participatory. But that's

> The big elephant in the room seems to be Matz comments that the  
> semantics of a meta/singleton/eigen class might be implemented via some  
> mechanism other than a class, which would certainly stir the pot a bit.

No elephant, from my perspective. That's yet another reason (aside from  
the general principle of respect for Matz's unique role) for not having  
the terminology free-for-all.

David

> **···**
>
> On Wed, 7 Dec 2005 gwtmp01@mac.com wrote:
> 
> > On Dec 6, 2005, at 10:11 AM, David A. Black wrote:
> 
> \_\_  
> David A. Black  
> dblack@wobblini.net
> 
> "Ruby for Rails", forthcoming from Manning Publications, April 2006!

---

<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:** [6 December 2005 16:23 UTC](https://rubytalk.org/t/subclassing-class/23031/20 "2005-12-06T16:23:02Z")

</div>

...all he wrote? 🙂

Oh, you know. Short-term, or some synonym for it 🙂

David

> **···**
>
> On Wed, 7 Dec 2005, David A. Black wrote:
> 
> > How about channeling these inspirations \*through\* the RCRs and  
> > discussions? I just can't see how throwing arbitrarily many home-made  
> > synonyms for language-level constructs at newcomers can be of the  
> > slightest benefit. In the short term I suppose it's exhilerating and  
> > makes people feel creative and participatory. But that's
> 
> \_\_  
> David A. Black  
> dblack@wobblini.net
> 
> "Ruby for Rails", forthcoming from Manning Publications, April 2006!

[Next page](https://rubytalk.org/t/subclassing-class/23031.md?page=2)