classses, interfaces, MI

[Matthias Felleisen <address@hidden>]

Over seven years, PLT Scheme has gone through several class systems. 

The cycle started like this. Matthew added classes because it was most
natural to write GUIs derived from the wx GUI library. The wx package came
in C++, so it was natural to start with an MI class system. Indeed, since 
we already had closures, classes were an organization system (with an
extensible recursive declaration mechanism) for closures. That kept things
orthogonal. 

Then we programmed. 

We noticed that MI was a pain to work with. What we really needed was the
ability to use the same class over and over again but with _different_
super classes. Indeed, you may want to write something like that:

 ; class -> class
 (define (add-some-methods a-class) (class ...))

 ; (listof classes) 
 (define some-new-classes (map add-some-methods list-of-classes))

So we threw out MI and instead focused on our MIXINs i.e. single-inheritance
with computed superclasses. Java could benefit from that, as we tried to
explain in a POPL paper. We also added interfaces because they were helpful
in thinking about the hierarchy and adding dynamic contracts. 

Then we re-programmed DrScheme. 

And again we noticed that we wanted methods, not classes, with all the
convenience that we give up. So Matthew changed classes and mixins and added
method-based versions. 

And we're reprogramming DrScheme again. 

We're pretty happy for now, but it doesn't mean the system will stay put. 
Fortunately, we have classes via (transparent) macros so that we can evolve 
it again, if needed. 

The key: reimplement one and the same large piece of software in a language
whose OO system evolves. Learn from that then let us know about your
experience. 

-- Matthias