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

["Anton van Straaten" <address@hidden>]

> 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.

I think you're absolutely right about blame - in the example I just gave
(before receiving your message), a statement like "assume class X is
Lockable" would place the blame firmly on the program making that claim.

> 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/).

I would think my suggestion could address this?  I'll have to read more
Flatt (there's a pun in there somewhere, but I can't put my finger on it...)

BTW, if you're building the blame concept into a programming language, you
should make sure that if the module to blame is written by someone else, all
messages should talk about blame; but if the module was written by the
person running the program, or his/her boss, it should use the term
'responsibility' instead!

Otherwise, the whole idea is going to be a hard sell...

Anton