Slate objects, from the root objects down, all respond to the message traits, which is conceptually shared behavior but is not as binding as a class is. It returns an object which is, by convention, the location to place shared behavior. Most Slate method definitions are defined upon some object's traits object. This is significant because cloning an object with a traits delegation slot will result in a new object with the same object delegated-to, so all methods defined on that traits object apply to the new clone. There is one core method which drives derivation:
Beneath this simple system is a level of indirection which allows for greater control when necessary over the combination of parent behaviors; for most purposes, they may be ignored. What is actually the case is that each object points to an object in a traitsWindow delegation slot. The object held there delegates directly to all parents above it; the various parents will be labeled traits1.. traitsN, and a separate slot is created for the particular prototype's shared method, called traits, and this is where most method definitions are concerned.
This allows for a control over the order of precedence (via addDelegate:before:valued: and addDelegate:after:valued:) for any prototype deep into the normal derivation chains. This means that nearly all of the problems of precedence in a multiple inheritance graph may be resolved flexibly.6 There is also a hint to the lookup procedure in the traitsWindow objects that a meta-level has been reached. Once one meta-transition has occurred during lookup, the algorithm will not traverse such a transition again; thus Slate avoids a lookup confusion between methods meant for regular objects and those meant for the traits themselves.
Brian T. Rice 2005-06-08