Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

To those who want abstract classes in Ruby

2 views
Skip to first unread message

Matthias Lampert

unread,
Aug 30, 2001, 4:55:20 AM8/30/01
to

Hi, folks!

There are people who miss a feature like abstract/virtual
classes in Ruby. I was one of them, I admit.

By the time I learned, though, that I could implement this
feature myself. Just like here.


#########################################################################
class Abstract
attr :attrib

def initialize( i_attrib )
@attrib = i_attrib
check4ForbiddenInstantiating
end


def method_a
crash4ViolationOfAbstractness("method_a")
end

def method_b
crash4ViolationOfAbstractness("method_b")
end

def crash4ViolationOfAbstractness( sMethodName )
raise "Ahem... You need to implement " +
"#{self.type.to_s}##{sMethodName} to use it!"
end

def check4ForbiddenInstantiating
if self.type.to_s == "Abstract"
raise "Sorry, lad! I'm abstract!"
end
end

end


class Concrete < Abstract
def initialize( i_attrib )
super(i_attrib)
end

def method_a
puts "This instantiation is " + attrib.to_s
puts "Implemented Abstract#method_a"
end
end


# Abstract.new( "forbidden!") # ==> ERROR!
obj = Concrete.new("allowed!")
obj.method_a
# obj.method_b # ==> ERROR!

#########################################################################


It's primitive, I know that, but it's a place to get started, and it did
a great job for me so far. Maybe one of the gurus can make a module of it;
would be great to create an abstract class semi-automatically. Perhaps I
can do it myself, but I need to be a guru first!


CU,

--

Matthias Lampert, Hamburg
Just another XP and Ruby fan


Nat Pryce

unread,
Aug 30, 2001, 6:36:52 AM8/30/01
to
There is very little need for this in Ruby, and it can be a drawback.

There is little need for this, by default, throws an exception when an
object is sent a message it does not understand.

It is a drawback because you now cannot instantiate an abstract class and
define per-instance methods. E.g. code like this is very useful:

a = Abstract.new
def a.method_a( n )
...
end
def a.method_b( n )
...
end

jwei...@one.net

unread,
Aug 30, 2001, 8:15:28 AM8/30/01
to
>>>>> "Matthias" == Matthias Lampert <m...@sph.de> writes:

Matthias> There are people who miss a feature like
Matthias> abstract/virtual classes in Ruby. I was one of them, I
Matthias> admit.

Matthias> By the time I learned, though, that I could implement
Matthias> this feature myself. Just like here.

I did something similar at one point. I didn't bother with the
constructor check, but I did implement a module method named
"abstract" that was used much like attr_reader and attr_accessor. For
example...

class Abstract
def do_something
an_abstract_method
end

abstract :an_abstract_method
end

Declaring a method to be abstract was equivalent to defining it like
this...

def an_abstract_method
fail "Abstract method an_abstract_method called"
end

Other than giving a more explicit error message, the effect was much
the same. Forgetting to define an abstract method would cause an
exception. The major benefit in my mind was that the abstract method
was clearly documented for the readers of class Abstract.

I didn't end up using the concept. It didn't work cleanly when trying
to use mixins to define abstract functions.

If someone is interested, I can dig up the code for it (although it
isn't hard to write from scratch).

--
-- Jim Weirich jwei...@one.net http://w3.one.net/~jweirich
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)


0 new messages