RE: Curl, multiple inheritance, and interfaces (was Re: cheerful static typing)

[Robert Bruce Findler <address@hidden>]

Quoting "Christopher Barber":
> > I'm saying that unless the class designer explicitly specifies
> > that a class
> > supports a particular interface, the fact that it happens to contain a set
> > of methods that look like they might belong to that interface isn't good
> > enough.  The methods that the compiler is seeing may not even be
> > related to
> > each other.  No matter when you check this, it's a very weak sort of type
> > check, that may give the appearance of being stronger than it really is,
> > since variables that are declared as e.g. Lockable, may not be.
> 
> All this is true, but think of the case in which you do not have the ability
> to add an "implements" clause to a class because it lives in a 3rd party
> library which you not allowed to change.

This brings us to the question of blame again. 

You must not implicitly retrofit that `implements' clause to that
class, unless you mean for that class to be blamed for violations of
the contracts in that interface. Instead, the right thing is to derive
a new class and have the derived class declare that it implements the
interface. This derived class lives in your code and thus you will be
blamed if it turns out that the class doesn't meet the interface --
after all, you were the one who claimed it did, not the original
implementor.

As a side point, sometimes you cannot derive another class since a
third person's code my be creating instances of the original class. The
correct fix to this problem is to abstract over the link from the
original class to the third person's code using a Factory pattern or by
enriching the programming language along the lines Matthew Flatt
suggests in his work (http://www.cs.utah.edu/~mflatt/).

Robby