Classes as a concept don't have to contain methods, and indeed even in C++ you can view a virtual method as an entity that stretches down through the class hierachy. Syntactically in C++, you implement (non-inline) member functions outside the class curlies, and then you have friend functions...

I *love* Dylan's Generic Function system. Current OO thinking seems to regard Objects as consisting of funtionality, not data. Priviledging methods/functions equally compared to data objects makes this world-view easier to express (strangely) as functions don't hang off data so much, and I feel it gives a more balanced view of the world.

Java's broken, broken, broken "OK, you've inhehited ten ABCs now code the funtionality" interface system is soooo weak (I program Java for a living). Multiinheritance I can save time and effort, make elegant designs or be mis-used like anything else. :-)

> Classes as a concept don't have to contain methods,
> and indeed even in C++ you can view a virtual method
> as an entity that stretches down through the class
> hierachy.

This was the biggest switch I had to make in thinking about object- orientation when switching to Dylan.  I had beforehand -- because of pollution caused by C++, Java, Eiffel, etc. -- always conflated the mostly orthogonal issues of state encapsulation, access control and functionality encapsulation into one "golden hammer" solution: classes.  It took looking into Dylan, Modula- 3 (to an extent) and other such languages for me to even realize that an alternative viewpoint was available.

Now, post-Dylan-switch, I map these concepts into different containers. State encapsulation belongs to classes.  Access control belongs to libraries

and modules.  Functionality encapsulation belongs to generic methods.  I find myself wrestling with the language less and the problem domain more now.  This, combined with access to some of the cool features of functional programming (not to mention the ability to effectively add new semantics to the language with hygenic macros) has confirmed my selection.

Of course now I can't convince any of my colleagues of the benefits of this switch.  They see methods without a "self" or "this" (implied or explicit) and the barriers snap up.  "That's not object-oriented programming!" is the endless refrain.