On Fri, 2005-03-04 at 21:12 +0100, Thomas Sandlaß wrote: > The roles themself beeing the least member of these classes---uninstanciable > "pure" > behaviour. The intersection type/role A&B is multiple inheritance (or is that > "roling"?):
I don't understand the question (I don't recognize the words "lubs" or "glbs", for example), but I don't think this has anything at all to do with multiple inheritance. Generalizing types on a class based on inheritance is micromanagement. It cares too much about how polymorphism works. This is why putting abstract, uninstantiable classes in languages that don't support multiple inheritance is a cure worse than the disease -- it recognizes that there's a problem with forcing all type equivalence to go through inheritance, but it adds a second type system alongside the first and classes again have to know too many details about how one particular class marks its equivalence. I don't think that roles are necessarily unsubstantiable; class and role names should occupy the same namespace. It ought to be possible to have class A with a particular set of methods and class B with a set of methods of the same name and similar enough semantics for the entire set of behavior of those methods and be able to mark class B as performing the A role and to be able to pass B objects into code that asks for A objects and have things just work without A or B necessarily having to share code and definitely without them being related to each other in any sort of inheritance relationship. Maybe there's not enough behavior in a role to make it a full class, but there's enough behavior that it's useful across classes horizontally and it deserves its own name. Maybe that's not helpful, but I did warn that I didn't understand the question! -- c
