Mixin

Mixins first appeared in Symbolics's object-oriented Flavors system (developed by Howard Cannon), which was an approach to object-orientation used in Lisp Machine Lisp. The name was inspired by Steve's Ice Cream Parlor in Somerville, Massachusetts:[1] The owner of the ice cream shop offered a basic flavor of ice cream (vanilla, chocolate, etc.) and blended in a combination of extra items (nuts, cookies, fudge, etc.) and called the item a "mix-in", his own trademarked term at the time.[2]

Mixins are a language concept that allows a programmer to inject some code into a class. Mixin programming is a style of software development, in which units of functionality are created in a class and then mixed in with other classes.[6]

A mixin class acts as the parent class, containing the desired functionality. A subclass can then inherit or simply reuse this functionality, but not as a means of specialization. Typically, the mixin will export the desired functionality to a child class, without creating a rigid, single "is a" relationship. Here lies the important difference between the concepts of mixins and inheritance, in that the child class can still inherit all the features of the parent class, but, the semantics about the child "being a kind of" the parent need not be necessarily applied.

1. It provides a mechanism for multiple inheritance by allowing one class to use common functionality from multiple classes, but without the complex semantics of multiple inheritance.[7]
2. Code reusability: Mixins are useful when a programmer wants to share functionality between different classes. Instead of repeating the same code over and over again, the common functionality can simply be grouped into a mixin and then included into each class that requires it.[8]
3. Mixins allow inheritance and use of only the desired features from the parent class, not necessarily all of the features from the parent class.[9]

In Simula, classes are defined in a block in which attributes, methods and class initialization are all defined together; thus all the methods that can be invoked on a class are defined together, and the definition of the class is complete.

In Flavors, a mixin is a class from which another class can inherit slot definitions and methods. The mixin usually does not have direct instances. Since a Flavor can inherit from more than one other Flavor, it can inherit from one or more mixins. Note that the original Flavors did not use generic functions.

In New Flavors (a successor of Flavors) and CLOS, methods are organized in "generic functions". These generic functions are functions that are defined in multiple cases (methods) by class dispatch and method combinations.

CLOS and Flavors allow mixin methods to add behavior to existing methods: :before and :after daemons, whoppers and wrappers in Flavors. CLOS added :around methods and the ability to call shadowed methods via CALL-NEXT-METHOD. So, for example, a stream-lock-mixin can add locking around existing methods of a stream class. In Flavors one would write a wrapper or a whopper and in CLOS one would use an :around method. Both CLOS and Flavors allow the computed reuse via method combinations. :before, :after and :around methods are a feature of the standard method combination. Other method combinations are provided.

An example is the + method combination, where the resulting values of each of the applicable methods of a generic function are arithmetically added to compute the return value. This is used, for example, with the border-mixin for graphical objects. A graphical object may have a generic width function. The border-mixin would add a border around an object and has a method computing its width. A new class bordered-button (that is both a graphical object and uses the border mixin) would compute its width by calling all applicable width methods—via the + method combination. All return values are added and create the combined width of the object.

In an OOPSLA 90 paper,[10] Gilad Bracha and William Cook reinterpret different inheritance mechanisms found in Smalltalk, Beta and CLOS as special forms of a mixin inheritance.

Other than Flavors and CLOS (a part of Common Lisp), some languages that use mixins are:

• Ada (by extending an existing tagged record with arbitrary operations in a generic)
• C# (since C# 8.0, by means of default methods of interfaces)[11]
• Cobra
• ColdFusion (Class based using includes and Object based by assigning methods from one object to another at runtime)
• Curl (with Curl RTE)
• D (called "template mixins"; D also includes a "mixin" statement that compiles strings as code.)
• Dart
• Factor[12]
• Groovy
• Java (since Java 8, by means of default methods of interfaces)
• JavaScript Delegation - Functions as Roles (Traits and Mixins)
• Kotlin
• Less
• Magik
• MATLAB[13]
• OCaml[14]
• Perl (through roles in the Moose extension of the Perl 5 object system)
• PHP's "traits"
• Python
• Racket (mixins documentation)
• Raku
• Ruby
• Rust
• Sass (A stylesheet language)
• Scala[15]
• Smalltalk
• Swift
• SystemVerilog
• XOTcl/TclOO (object systems builtin to Tcl)[16]
• TypeScript (mixins documentation)
• Vala

Some languages do not support mixins on the language level, but can easily mimic them by copying methods from one object to another at runtime, thereby "borrowing" the mixin's methods. This is also possible with statically typed languages, but it requires constructing a new object with the extended set of methods.

Other languages that do not support mixins can support them in a round-about way via other language constructs. For example, Visual Basic .NET and C# support the addition of extension methods on interfaces, meaning any class implementing an interface with extension methods defined will have the extension methods available as pseudo-members.

Java 8 introduces a new feature in the form of default methods for interfaces.[20] Basically it allows a method to be defined in an interface with application in the scenario when a new method is to be added to an interface after the interface class programming setup is done. To add a new function to the interface means to implement the method at every class which uses the interface. Default methods help in this case where they can be introduced to an interface any time and have an implemented structure which is then used by the associated classes. Hence default methods add the ability to applying the mixin concept in Java.

Interfaces combined with aspect-oriented programming can also produce full-fledged mixins in languages that support such features, such as C# or Java. Additionally, through the use of the marker interface pattern, generic programming, and extension methods, C# 3.0 has the ability to mimic mixins. With Dart 2.7 and C# 3.0 came the introduction of extension methods which can be applied, not only to classe, but also to interfaces. Extension Methods provide additional functionality on an existing class without modifying the class. It then becomes possible to create a static helper class for specific functionality that defines the extension methods. Because the classes implement the interface (even if the actual interface doesn’t contain any methods or properties to implement) it will pick up all the extension methods also.[3][4][21] C# 8.0 adds the feature of default interface methods.[22][23]

ECMAScript (in most cases implemented as JavaScript) does not need to mimic object composition by stepwise copying fields from one object to another. It natively[24] supports Trait and mixin[25][26] based object composition via function objects that implement additional behavior and then are delegated via call or apply to objects that are in need of such new functionality.

trait Singer{
  def sing { println(" singing … ") }
  //more methods
}

class Bird extends Singer

class Person
class Actor extends Person with Singer
class Actor extends Singer with Performer

class Person{
  def tell {  println (" Human ") }
  //more methods
}

val singingPerson = new Person with Singer
singingPerson.sing

// Allows for types to "speak"
trait Speak {
	fn speak();

	// Rust allows implementors to define default implementations for functions defined in traits
	fn greet() {
		println!("Hi!")
	}
}

struct Dog;

impl Speak for Dog {
	fn speak() {
		println!("Woof woof");
	}
}

struct Robot;

impl Speak for Robot {
	fn speak() {
		println!("Beep beep boop boop");
	}

	// Here we override the definition of Speak::greet for Robot
	fn greet() {
		println!("Robot says howdy!")
	}
}

protocol ErrorDisplayable {
    func error(message:String)
}

extension ErrorDisplayable {
    func error(message:String) {
        // Do what it needs to show an error
        //...
        print(message)
    }
}

struct NetworkManager : ErrorDisplayable {
    func onError() {
        error("Please check your internet Connection.")
    }
}

• Abstract type
• Decorator pattern
• Policy-based design
• Trait, a similar structure that does not require linear composition

• MixIn at Portland Pattern Repository
• Mixins in ActionScript
• The Common Lisp Object System: An Overview by Richard P. Gabriel and Linda DeMichiel provides a good introduction to the motivation for defining classes by means of generic functions.