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
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
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)