matz / netlab.co.jp (Yukihiro Matsumoto) writes: > |There does not seem to be any parallel concept in > |Ruby. On the other hand, maybe I don't need it. > > Since Ruby is a dynamic typed language, you don't NEED pure virtual > member functions. But if you want to describe the need for > redefinition of a method implicitly by a program, you can, for > example: > > def must_be_redefined() > raise NotImplementError, "should be redefined" > end I agree that you probably don't need it--in fact, overcoming the notion that I need to implement classes hierarchically is one of the things I find most difficult about Ruby. At the end of the day, if an object responds to the right messages, it can play. However, it's fun to think about implementing abstract base classes, just to see how it could be handled. One way is to make the abstract base class a module, and include it in any class that implements that interface. Let's invent a new 'keyword' to specify the names of the methods in that base class. module AbstractStack abstract :push, :pop end So here we've created our abstract base class (as a module). Lets create an implementation. class ConcreteStack include AbstractStack # ... end And try it c = ConcreteStack.new c.push(1) #=> (eval):1:in `push': push not implemented (NotImplementError) from -:23 Excellent - we didn't implement push, so we got a message. So now all that's left is to implement this new-fangled 'abstract' thing. We do that by adding a method to class Module. These methods are then available during module definition: class Module def abstract(*names) for name in names class_eval %{def #{name}(*a) raise NotImplementError, "#{name} not implemented" end} end end end And that's it. One of the benefits of implementing the abstract bases in modules is that you can mix in as many as you want: you get multiple inheritance from base classes. And the neat thing about Ruby is that your can effectively extend the language this way, all in Ruby. Regards Dave