On Sun, 2003-01-05 at 10:17, Robert wrote:
> in order to clarify my understanding of the issue at hand I tried to
> summarize the discussion.  Comments are welcome.

Good Summary ... I'd like to add a few comments.

There are several reasons people like interfaces (and DbC for that
matter) ...

(a) They enable compile time static type checks.
(b) They document the intended behaviour

If (a) is your goal, then Ruby is probably the wrong platform.  There
has been much discussion of this issue in the past (check the archives),
and I'm not willing to take this thread down that path (for the moment).

Point (b) is a worthy goal and I think it is interesting to pursue.  

I've found that when doing Test-Driven-Design, the unit test cases
provide much the same information as an explicit interface (and
contract).  Perhaps the documentation issue with interfaces can be
addressed in the test case.  

Here's an example ...

  module ImplementsFoo
    def test_bar
      result = @obj.bar(1,2)
      assert something interesting about the result
    end
    def test_baz
      assert_responds_to(@obj, :baz)
    end
  end

  class TestFooImpl < Test::Unit::TestCase
    include ImplementsFoo
    def setup
      @obj = FooImpl.new
    end

    def test_extra_stuff
      # Assert behaviour beyond basic Foo stuff
    end
  end

The "include ImplementsFoo" line in the FooImple test case not only
documents that FooImpl implements a Foo interface, it also assures us
that FooImpl actual behaves as a Foo is expected to behave.

All in all, I like this.  The test case clearly documents that the
behavior of a Foo object is provided.  It actually checks for that
behavior.

-- 
-- Jim Weirich     jweirich / 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)