Em Qua, 2009-07-08 às 12:49 -0700, Ovid escreveu: > Behavioral: if you are primarily relying on roles to provide behavior > (as we do at the BBC), then silently discarding the role's behavior by > providing a method of the same name in your class can lead to very > confusing bugs. I've lost a lot of time debugging this behavior.
That's actually a tipping point, and I'm thinking we never conceptually extrapolated the use of Roles to a point that competing Roles in a composition are bringing methods to the class that are actually relevant to that roles, but doesn't mix well with the semantics of the composed class. Maybe what we need is a way to define methods that are not composed to the class at all, but are there just for implementation sake. That could probably mean that methods declared as privates in the role should not be composed in the class, and the lookup of private methods should honor the original place of declaration... daniel
