From: Robert Feldt <feldt@...>
Date: 2002-02-06T19:09:13+09:00
Subject: Re: Subclassing vs Subtyping (partly OOP vs FP)

On Tue, 5 Feb 2002, Dave Thomas wrote:

> Robert Feldt <feldt@ce.chalmers.se> writes:
> 
> > 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 think I was thinking about something less ambitious/. Say you have
> out friend BagCollectable that implements bag functionality for some
> container. BadCollectable relies on its host class implementing
> methods #add, #remove, #includes? and #each, and exports a bunch of
> cosmetic methods based on these. We have a set of implementations:
> 
>   class BTreeBag
>     include BagCollectable
>     ...
>   end
> 
>   class ArrayBag
>     include BagCollectable
>     ...
>   end
> 
>   class LinkedListBag
>     include BagCollectable
>     ...
>   end
> 
> etc
> 
> Then we _could_ arrange it so that BagCollectable did some basic
> checking if (say) the -d flag was set:
> 
> 1. It could check that classes it was mixed in to defined the methods
>    it needed.
> 
Minor quirk: I often write includes on the top so needed methods not yet
defined?!

> 2. It could generate some basic tests, exercising each class in to
>    which it is mixed by calling their #add, #remove, etc methods
> 
Yeah, but if the tests are more than checking that the method is there we
need to give some hints about the semantics => we can as well specify the
contract?!

> Then take it a step further, and break these tests out into a separate >
> module:
> 
>   class BTreeBag
>     implements BagProtocol
>     includes   BagCollectable
> 
>     ...
>   end
> 
Sure, doesn't sound too hairy. Might be some conflicts with a truly
dynamic philosophy (I want to add the needed methods later etc) but maybe
not a problem in practice.

Regards,

Robert