Re: Jonathan Rees on OO

[Dan Weinreb <address@hidden>]

   Date: Tue, 11 Dec 2001 16:42:31 -0500
   From: Scott McKay <swm@hotdispatch.com>

     7. Sadly, there are no interfaces in Dylan, although you can use an
       abstract class to do a pretty good job of simulating them (Dylan should
       have grabbed Flavor's :required-methods or something :-)

Back when Dave Moon was doing New Flavors (which followed the original
Flavors and preceeded CLOS), I tried lobbying for interfaces, but I
was never able to convince Moon to put them in.  (This, of course, is
long before Java existed.)

It always seemed to me that the language ought to have one sort of
construct to say "this is what it is to be an input stream", and a
different sort of construct to say "here is some useful implementation, in
the form of an abstract base class, that you might want to use if you
intend to build an implementation of an input stream".  I felt that I
ought to have the right to make an input stream without sharing any
implementation with anyone if I didn't want to.

So I was happy when I saw that Java had separated the concept of
interface from the concept of abstract base class.

Still, sometimes my colleagues get a little bit annoyed at me when I
create an interface for something, and then it turns out that it's
convenient to have an abstract base class with some useful little
shared implementation, and in fact every concrete class that
implements the interface does indeed extend that base class.  They
come to me and say, why bother with the interface?  They say, having
both the interface and the base class is verbose and redundant.  I can
see what they mean, but I still think that using the interface is
the Right Thing in some sense.

(You could sort of imagine a Java-variant that allowed interfaces to
be used as types but didn't allow classes to be used as types.  Then
you'd really have to use interfaces in the above case.  But I don't
imagine a lot of people would like such a change; I don't even think I
would...)

I always wished that interfaces could say more than just "here are all
the methods, their names and type constraints".  I'd like for the
definition of an output stream to assert that if write-character of
'a' on an object is followed, with no intervening operations, by a
write-character of 'b', then that MUST have the same effect as a
write-string of "ab".  Right now I can only say it in comments.  This
kind of declarative constraint can make it easier to reason about
programs sometimes.

I once talked about this at MIT, and someone pointed out that what I
was asking for was actually a baby version of what some of the
symbolic math people at MIT were doing.  They wanted a language that
could say that the definition of a "ring" asserted that addition was
associative, etc, etc.  (I am using the word "ring" in the context of
"abstract algebra", as in "group theory", etc.)  Rich Zippel and Carl
Hoffman at MIT showed me some stuff along these lines that seemed very
cool and like a major new direction for object-oriented programming.
Unfortunately I don't have any citations for this.  Of course knowing
that addition is associative makes programs easier to understand, at
least a little bit.  (Warning: don't try this with floating point!)

Another kind of additional declarative constraint that could be added
to interfaces is rules about sequencing.  In the area that I work in
these days ("business process management"), we want to be able to have
interfaces that say things like "you can only do operation foo after
you have done operation bar".  I guess for streams one might want the
interface to make clear that you're going to get an exception if you
try to do write-character after (with no intervening operations) you
do close.