Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > Subclassing Class.

Reply
Thread Tools

Subclassing Class.

 
 
John Carter
Guest
Posts: n/a
 
      12-06-2005
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...
* State.
* 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
def initialize( foo_state)
@foo_state = foo_state
end

def foo_fu( bah)
# Knowledge of Foo making
end

def create( needs_fu, stuff)
Foo.new( foo_fu( needs_fu), @foo_state, stuff)
end
end

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

We really want

class Foo < Class
def initialize( foo_state)
@foo_state = foo_state
end

def foo_fu( bah)
# Knowledge of Foo making
end

def new( needs_fu, stuff)
super( foo_fu( needs_fu), @foo_state, stuff)
end
end

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


Except ruby doesn't like that
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
# Add state and behaviour to Class
end

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

FooClass Foo < FooParent
# 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 : http://www.velocityreviews.com/forums/(E-Mail Removed)
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.


 
Reply With Quote
 
 
 
 
Aredridel
Guest
Posts: n/a
 
      12-06-2005
> We really want
>
> class Foo < Class
> def initialize( foo_state)
> @foo_state = foo_state
> end
>
> def foo_fu( bah)
> # Knowledge of Foo making
> end
>
> def new( needs_fu, stuff)
> super( foo_fu( needs_fu), @foo_state, stuff)
> end
> end
>
> foo = Foo.new( 'fooless', 'stuffed')
>
>
> Except ruby doesn't like that
> 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
def self.new(needs_fu, stuff) # Could be Foo.new, too, but self keeps
us warm and DRY.
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.

Aria



 
Reply With Quote
 
 
 
 
Logan Capaldo
Guest
Posts: n/a
 
      12-06-2005

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...
> * State.
> * 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
> def initialize( foo_state)
> @foo_state = foo_state
> end
>
> def foo_fu( bah)
> # Knowledge of Foo making
> end
>
> def create( needs_fu, stuff)
> Foo.new( foo_fu( needs_fu), @foo_state, stuff)
> end
> end
>
> factory = FooFactory.new( 'foo juice')
> foo = factory.create( 'footile')
>
> We really want
>
> class Foo < Class
> def initialize( foo_state)
> @foo_state = foo_state
> end
>
> def foo_fu( bah)
> # Knowledge of Foo making
> end
>
> def new( needs_fu, stuff)
> super( foo_fu( needs_fu), @foo_state, stuff)
> end
> end
>
> foo = Foo.new( 'fooless', 'stuffed')
>
>
> Except ruby doesn't like that
> 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
> # Add state and behaviour to Class
> end
>
> And then instead of saying...
> class Foo < FooParent
> # Add state and behaviour to FooParent
> end
> we need to be able to say...
>
> FooClass Foo < FooParent
> # 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 : (E-Mail Removed)
> 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.
>


Why are you trying so hard?

class Foo
# state and behavior for Foo the Class
# using class instance variables and singleton methods
# eg:
@foo_state = foo_state # this works believe it or not
# etc.
@old_new = method(:new)
def self.new(needs_fi, stuff)
@old_new.call(foo_fu(needs_fu, @foo_state, stuff)
end
end

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



 
Reply With Quote
 
David A. Black
Guest
Posts: n/a
 
      12-06-2005
Hi --

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

^^^^^^^^^^

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
__
David A. Black
(E-Mail Removed)

"Ruby for Rails", forthcoming from Manning Publications, April 2006!


 
Reply With Quote
 
Trans
Guest
Posts: n/a
 
      12-06-2005
> 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.

 
Reply With Quote
 
gabriele renzi
Guest
Posts: n/a
 
      12-06-2005
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?
 
Reply With Quote
 
John Carter
Guest
Posts: n/a
 
      12-06-2005
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?


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 : (E-Mail Removed)
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.


 
Reply With Quote
 
John Carter
Guest
Posts: n/a
 
      12-06-2005
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.
> 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.


Err. Right.

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

Now I wanted
class AbstractFoo < Class
end

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

I actually also want....
class ConcreteFooClass < AbstractFooClass
end

class OtherConcreteFooClass < AbstractFooClass
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 : (E-Mail Removed)
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.


 
Reply With Quote
 
John Carter
Guest
Posts: n/a
 
      12-06-2005
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

> ^^^^^^^^^^
>
> 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.

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 : (E-Mail Removed)
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.


 
Reply With Quote
 
David A. Black
Guest
Posts: n/a
 
      12-06-2005
Hi --

On Tue, 6 Dec 2005, John Carter wrote:

> 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

> > ^^^^^^^^^^
> >
> > 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
__
David A. Black
(E-Mail Removed)

"Ruby for Rails", forthcoming from Manning Publications, April 2006!


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Thread safety when subclassing the Page class thechaosengine ASP .Net 2 12-10-2004 02:48 PM
Subclassing Controls TheStripe ASP .Net 2 09-27-2004 01:17 PM
SubClassing a TextBox Felbrigg ASP .Net 0 04-27-2004 09:05 AM
Subclassing from System.Web.UI.Page - Designer Error =?Utf-8?B?Q2h1Y2sgSGFlYmVybGU=?= ASP .Net 1 02-20-2004 05:05 PM
Subclassing UserControl makes the Visual Studio designer does not work S Guiboud ASP .Net 1 07-18-2003 03:55 PM



Advertisments