The term mixin was first used to describe a style of LISP programming that combines classes using multiple inheritance [Moon, OO with Flavors]. Since then, however, mixins have been more commonly defined as types whose supertypes are declared parametrically [Bracha and Cook, Mixin-based inheritance], and it is in this sense that we use the term.
The more complex method combination mechanisms of CLOS can also be modeled in this framework. For example, ifI think they understand CLOS just fine, even if they don't quite appreciate what it allows. Bottomline: I find the distinction between auxiliary methods and superclass parameters to be fairly minor. In either case you have some primitives that ideally include a single concern, and combination mechanisms for composing them. Both rely on programmer taste to ensure the universe of concerns is orthogonal. Yes, Bracha and Cook seem to care more about "encapsulation", something I personally don't care about. But this is more an example of Steve Yegge's liberal vs conservative programmers than two sides that speak different languages using the same words. Conservatives typically tend to have experienced larger scales where it's easier for poor abstractions to slip through into code.and
beforemethods were distinguished then the base class, whose methods would be called after all other methods, could arrange for the last
aftermethod to call the primary method, and the last primary method to call the