On 10/28/05, Rob Kinyon <[EMAIL PROTECTED]> wrote: > Now, it's obvious why a class would have to resolve that conflict. I > would say that a role would have to resolve the conflict is that a > role should present a consistent API to the rest of the world. In > other words, I want to be able to depend on the fact that classA does > roleAB means something in terms of the functionality that classA > provides to me. I don't want it to be a glorified can() check. That > does no-one any good.
Most certainly. Implicit in a role or a theory is its algebra (though we've talked about QuickCheckish ways to make it explicit). For instance, technically the VectorSpace theory only requires you to define identity, addition, and scalar multiplication. However, in order to honestly do VectorSpace, addition has to be commutative, which is something that the compiler usually is not able to check. And that's why you have to explicitly say that your class "does" the role, rather than it just inferring that from the methods you provide. You may have named your methods the same, but there's no guarantee that you obey the role's algebra. By saying that your class "does" the role, you are promising that these methods do indeed obey the necessary algebra. So in a way, it's a kind of glorified can(). But in another way, it does guarante certain kinds of behavior from the implementing objects. If you do a role and override a method that violates what the role is supposed to guarantee, then you don't really do that role, even though you do as far as the compiler knows. It's a conceptual contract, not a computationally rigorous one. On the computational level, a role is little more than an interface with defaults. Luke
