From: Robert Feldt <feldt@...>
Date: 2002-02-05T03:37:17+09:00
Subject: Re: Subclassing vs Subtyping (partly OOP vs FP)

On Mon, 4 Feb 2002, Dave Thomas wrote:

> Robert Feldt <feldt@ce.chalmers.se> writes:
> 
> > However, I found it relevant since it made me think about why this
> > would not happen in Ruby. My conclusion was not so much that this is
> > a question of Ruby or not but about whether I think enough about the
> > contracts involved. Also that it could be a good thing to make the
> > implicit protocols more explicit (by more "formal" unit tests?).
> 
> Robert:
> 
> That's a good point. How would you go about documenting protocols
> using unit tests? Could it be a function of mixin: by including a
> particular mixin, you're adding a protocol to your class. Could the
> mixin contain tests to check that the classes it is mixed in to are up
> the the task?
> 
> Say BagCollectable was a module defining a set of helper methods for
> bag, and it relied on the classes that used it implementing #add,
> #remove, #contains?, and #each. At the very least, as it was included
> into a class, it could check that these methods exist. But how could
> we go further? How could it perform some kind of semantic check of
> these methods? If we could pull that off, we'd have something
> interesting.
> 
I'm not sure its what you're on to here but a part of what I'm working on
for my thesis is a scheme where you write generalized unit tests as
contracts. A test system can test that objects/classes adhere to the
contract. I like to think of this as something like a pragmatic,
lightweight formal method with a natural transition path from XP-style
unit testing but I'm unsure how valuable it'll be. A precursor to this was
[ruby-talk:10855]. A downside with a more abstract notation is that it
might be  easier to mess up (ie. introduce bugs in the spec), not as easy
to understand and won't document the code as much as some simple, concrete
unit tests will. So the extra trouble will not always be worth it.

I guess there is no easy way out of the problem that you can't  
semantically check methods unless you describe the semantics in a
machine-understandable form. The good thing with describing the semantics
is that we get an oracle that can be used for testing.

I've mostly been thinking of this as being done off-line but maybe it
might be useable also "on-line" as when including or inheriting, as you
propose.

Regards,

Robert