Hi --

On Wed, 15 Mar 2006, benjohn / fysh.org wrote:

>> I've been following the discussion on abstract method declaration with
>> some interest.  It seems to me that the ideal implementation should not
>> only throw an exception on unimplemented methods, but also must pass
>> Matz's example (implementation provided by base classes) and the
>> method_missing example.
>
> :) I like your approach, and I think it's extremely close. I'd change
> one of your tests a little though:
>
>>   # Here we make sure that not implementing the abstract method in the
>>   # child class will cause an exception when the method is invoked on
>>   # the child object.  We don't particularly care what exception is
>>   # thrown, but the exception message must mention the missing method
>>   # by name.
>>   def test_unimplemented_abstract_method_throws_exception
> ...
>
> It would be preferable I think, if a more helpful error message were
> given, instead of simply the method being missing.
>
> And while I suspect you're being a little flipant, I like your
> implementation - it does do nearly everything that's desired.

I don't think Jim is being flippant at all.  He's provided a fantastic
illustration of something that's true generally about Ruby, namely
that it is incredibly expressive.  Many of the twists and turns one
takes in trying to get Ruby to do, or be, this or that end up adding
up to a slip-knot; and what you really have to do is something that
looks negligible.

I'm happy without abstract methods in Ruby but it's worth the lengthy
discussion to get to Jim's post :-)


David

-- 
David A. Black (dblack / wobblini.net)
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

"Ruby for Rails" chapters now available
from Manning Early Access Program! http://www.manning.com/books/black