Traits & Mixins

## Two families that look alike from the outside Both models let you write a bundle of methods once and attach it to unrelated classes. The difference is what the composition *means*. **Flattening.** The composed class is defined to be equivalent to a class in which all the borrowed methods were written directly. Nothing is inserted into the inheritance chain, so there is no notion of the unit's "position", and the same set of units composed in any order gives the same class. Because there is no order, a name appearing in two units cannot be resolved by precedence - the language must report it and offer explicit operators to resolve it. **Chain insertion (mixin).** The unit is spliced into the lookup chain as a pseudo-ancestor. Method lookup then works exactly as it always did, walking the chain until it finds a match, so the winner is whichever unit was inserted closest. Order is now semantically significant, and because the unit has a position, a unit can forward to whatever sits after it. ## Concrete languages **Pharo/Squeak (Scharli, Ducasse et al.)** invented the trait in the flattening sense. A trait provides methods, requires others, and carries no state. Composition uses two operators: **exclusion** (`T - {#m}`), which removes a method so the other provider wins, and **aliasing** (`T @ {#newName -> #m}`), which keeps both under different names. The flattening property is stated as a design guarantee: a method's meaning does not depend on which traits it was composed with. **PHP** adopted the same shape. `use A, B;` where both define `say()` is a fatal compile-time error; you write `use A, B { A::say insteadof B; B::say as loudSay; }`. Precedence is fixed and small: the class's own definition wins over any trait, a trait wins over an inherited parent method. Note that this is precedence between *layers*, not between traits - between two traits there is no ordering rule at all, which is the flattening property showing through. **Rust** is flattening with the conflict pushed even later. Implementing two traits that both define `m` for one type is entirely legal. Only a call `x.m()` with both traits in scope is ambiguous, reported as multiple applicable items, and disambiguated with `Trait::m(&x)` or `<T as Trait>::m(&x)`. Rust also has coherence rules, so two independent crates cannot both provide the same trait implementation for the same type - the "two libraries collided" scenario that PHP and Ruby must handle by hand is structurally impossible. **Ruby** is the canonical mixin. `include M` inserts `M` into the ancestor chain *after* the class, so the class's own methods win; `prepend M` inserts it *before* the class, so the module can wrap the class's own method and call `super` to reach it. Multiple `include`s stack, with the most recently included nearest. `Module#ancestors` prints the resulting chain, and the whole design is order-sensitive by construction. **Scala** calls its unit a trait but composes it by linearization, which is chain insertion: `class C extends A with B` places `B` ahead of `A`, and `super` inside a trait means the next trait in the concrete class's linearization. That is what makes the stackable-modification idiom possible - each trait decorates the one behind it. Scala adds a guard the other chaining languages lack: it only lets linearization pick a winner when the members are related by `override`. Two unrelated concrete members with the same signature is a compile error demanding an explicit override, so accidental collisions are loud while intentional stacking is silent. ## Trade-offs Flattening gives **local reasoning**: read the class, read each unit, and you know the result; reordering the composition clause cannot change behaviour; every collision is surfaced at compile time. What it cannot express is "wrap the implementation that would otherwise have been used", because there is no ordering and therefore no previous implementation to name. A logging or memoizing decorator has to be written as an explicit wrapper object. Chain insertion gives exactly that missing power - each unit can intercept and forward, so cross-cutting concerns compose into a pipeline - and it makes accidental collisions cheap to *ignore*, which is also its danger: nothing tells you that a module you included silently displaced a method from another. It also makes behaviour non-local, since the effective chain is a property of the concrete class, decided far from either unit. ## Answering well Name the two models, give the defining property of each in one sentence (order-independence versus positional forwarding), attach at least two languages to each, and mention the operators each model needs: exclusion and aliasing for flattening, insertion position and forwarding for chaining. The sharpest observation available is Scala's hybrid - chain semantics, but loud on collisions that were not declared as overrides.