I'm having difficulty finding my around the Dylan libraries because the methods are not contained in the classes! But I don't think this is an inherent flaw in the way Dylan libraries are structured. I think it's just a temporary thing while I get used to a paradigm that is different than the one that I'm used to.

I've used different OO languages and libraries, but for more than a decade (closer to 2) I've always thought of methods as being part of classes. My problem with SI libraries is not a problem with expectations or perception; it is a problem with the overly- complex structure of those libraries.

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 inherited ten ABCs now code the funtionality" interface system is soooo weak (I program Java for a living). MI ( multi inheritance) can save time and effort, make elegant designs or be mis-used like anything else. :-)