In several ObjectOriented languages I have used and in DesignPatterns in general, objects tend to be equated with their roles. This leads to weak objects and mangled dependence on other objects for a number of roles that one object should have. In ExtendedObjectTcl, mixins provide a way to define roles apart from an object. This allows objects to just be objects. The purpose of an object is evident from the class definition as it is short and only contains the most core abilities. Any additional ability can be refactored into mixins.

 Class Rock

 Rock parameter {
    mass
    hardness
 }

 Class Throwable

 Throwable instproc throw { } {
   ...
 }

 Rock instmixin Throwable
A rock is not necessary throwable, but some are. There are many other things that are throwable as well. Making a class hierarchy based on an item's ability to be thrown is not very reusable. Adding this ability to specific classes or specific objects is more useful.

-- BenThomasson

''I'm unfamiliar with ExtendedObjectTcl. How do you specify unique behavior at the intersection of Throwable and Rock?''