use Class::Trait 'debug';
[download]

Traits Language

---

method dictionary:	D	::= {} | { x[1] -> m[1], ... , x[n] -> m[n] }
trait expression:	T	::= N[t] | T + T | T - x | T[x => y]
trait definiton:	T{def}	::= N[t] = D | N[t] = D with T
fields:	F	::= {} | { f[1], f[2], ... , f[n] }
class expression:	C	::= nil | N[c] | F in D extends N[c] | F in D with T extends N[c]
class definition:	C{def}	::= N[c] = C

---

D denotes a method dictionary, which is either empty or contains a finite number of services (i.e., bindings of labels to methods) in which all of the labels x[i] are distinct.

T denotes a trait expression, which can be a named trait N[t], the symmetric composition T + T of two traits, or a trait that is subject to an exclusion T - x or an alias T[x => y].

A trait definition (T{def}) binds a trait name N[t] to one of two forms: D, a method dictionary, or N[t] = D with T, a method dictionary that adds methods to (and possibly overrides methods from) a trait.

F is a possibly empty set of variable (or field) names; it is not important for our purposes whether these are instance variables, class variables, or static variables.

C denotes a class, which can be nil, a named class N[c], or a conventional class (F in D extends N[c]), which consists of some fields F, a method dictionary D, and a named superclass N[c]. In addition, a class can be structured F in D with T extends N[c]; the structured class acquires methods from the trait T augmented (and possibly overridden) by those from the explicit method dictionary D.

Finally, a class definition C{def} is simply a binding of a class name N[c] to a class C.

---

Model for Traits

Traits are essentially sets of bindings of labels to methods; the labels name the methods. We call these bindings services. Traits both provide services (i.e., the methods implemented) and require services (i.e., those that are invoked on the class using the trait). When we say that a class or a trait provides a service with a particular label we mean that a binding of that label to a method exists. When we say that a service with a particular label is required, we mean that a binding of that label to a method needs to exist.

Traits and Classes

Traits are subordinate to classes in several ways. Unlike classes, traits bind neither self nor super. Classes can contain fields and methods in classes can refer to these fields, so it is possible for classes to provide accessor methods. In contrast, traits do not contain fields, and as a consequence methods in traits cannot refer to fields. However, because the requirements of a triat method can be met by accessor methods, a trait methods can access state indirectly.

A class is built up from traits, methods, and a single superclass using single inheritance. If the traits conflict, the class can eliminate the conflict by overriding the conflicting methods. "super" is bound only at the point that a class is composed, and "self" refers to an instance of a composed class.

Trait operations

We introduce summation (+), exclusion (-), aliasing (=>) and overriding (>) as mechanisms for composing and modifying traits. When traits are composed with +, labels that are bound to different methods will conflict; we represent this by binding the label as a method conflict (#) in the sum. The > operation is intended to be used to override these method conflicts (#) with proper methods.

Summation composes two traits, forming the union of non-conflicting bindings and "disabling" the conflicting bindings.

For example:

    {a -> m[1], b -> m[2], c -> m[3]} + {a -> m[1], b -> m[3]}
[download]

results in:

     
    { a -> m[1], b -> #, c -> m[3] }
[download]

Exclusion removes a binding from a trait. This can be used to remove a binding to avoid a conflict.

For example:

    { a -> m[1], b -> # } - b
[download]

results in:

    { a -> m[1] }
[download]

Aliasing introduces an additional name for an existing method.

For example:

    { a -> m[1], b -> m[2] } [ c => b ]
[download]

results in:

    { a -> m[1], b -> m[2], c -> m[2] }
[download]

When composing classes or traits, we may need to replace conflicts by proper methods. For this reason we introduce the > operator. A trait T[1] may replace some of the bindings in another trait T[2]. Not that the overriding operation is on traits and not on specific bindings.