[go: nahoru, domu]

Jump to content

Edit filter log

Details for log entry 32,417,075

14:23, 20 April 2022: Newton toto (talk | contribs) triggered filter 135, performing the action "edit" on Mixin. Actions taken: Disallow; Filter description: Repeating characters (examine)

Changes made in edit

*[[Racket (programming language)|Racket]] ([http://docs.racket-lang.org/guide/classes.html#(part._.Mixins) mixins documentation])
*[[Racket (programming language)|Racket]] ([http://docs.racket-lang.org/guide/classes.html#(part._.Mixins) mixins documentation])
*[[Raku (programming language)|Raku]]
*[[Raku (programming language)|Raku]]
*[[Ruby (programming language)|Ruby]]
*[[Rust (programming language)|Rust]]
*[[Rust (programming language)|Rust]]
*[[<ref>Traits in Rust</ref>https://doc.rust-lang.org/book/ch10-02-traits.html (programming language)|Rust]]
*[[Ruby (programming language)|Ruby]]
*[[Scala (programming language)|Scala]]<ref>{{cite web |url=http://docs.scala-lang.org/tutorials/tour/mixin-class-composition.html | title=Mixin Class Composition |publisher=[[École polytechnique fédérale de Lausanne]] |accessdate=16 May 2014}}</ref>
*[[Scala (programming language)|Scala]]<ref>{{cite web |url=http://docs.scala-lang.org/tutorials/tour/mixin-class-composition.html | title=Mixin Class Composition |publisher=[[École polytechnique fédérale de Lausanne]] |accessdate=16 May 2014}}</ref>
*[[XOTcl]]/[http://wiki.tcl.tk/18152 TclOO] (object systems builtin to [[Tcl]])<ref>[http://media.wu-wien.ac.at/doc/tutorial.html#mixins Mixin classes in XOTcl]</ref>
*[[XOTcl]]/[http://wiki.tcl.tk/18152 TclOO] (object systems builtin to [[Tcl]])<ref>[http://media.wu-wien.ac.at/doc/tutorial.html#mixins Mixin classes in XOTcl]</ref>
val singingPerson = new Person with Singer
val singingPerson = new Person with Singer
singingPerson.sing
singingPerson.sing
</syntaxhighlight>

=== In Rust ===
Rust makes extensive use of mixins via ''traits''. Traits, like in Scala, allow user to implement certain behaviour for a defined type. They are also used for [[Generic programming|generics]] and [[dynamic dispatch]], which allow for types with same traits to be used interchangeably statically or dynamically at runtime respectively.

<syntaxhighlight lang="rust">
// Allows for types to "speak"
trait Speak {
fn speak();

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

struct Robot;

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

struct Dog;

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

// Here we override the definition of Speak::great on Dog
fn great() {
println!("Robot says howdy!")
}
}
</syntaxhighlight>
</syntaxhighlight>


Action parameters

VariableValue
Edit count of the user (user_editcount)
0
Name of the user account (user_name)
'Newton toto'
Age of the user account (user_age)
1732
Groups (including implicit) the user is in (user_groups)
[ 0 => '*', 1 => 'user' ]
Rights that the user has (user_rights)
[ 0 => 'createaccount', 1 => 'read', 2 => 'edit', 3 => 'createtalk', 4 => 'writeapi', 5 => 'viewmywatchlist', 6 => 'editmywatchlist', 7 => 'viewmyprivateinfo', 8 => 'editmyprivateinfo', 9 => 'editmyoptions', 10 => 'abusefilter-log-detail', 11 => 'urlshortener-create-url', 12 => 'centralauth-merge', 13 => 'abusefilter-view', 14 => 'abusefilter-log', 15 => 'vipsscaler-test', 16 => 'collectionsaveasuserpage', 17 => 'reupload-own', 18 => 'move-rootuserpages', 19 => 'createpage', 20 => 'minoredit', 21 => 'editmyusercss', 22 => 'editmyuserjson', 23 => 'editmyuserjs', 24 => 'purge', 25 => 'sendemail', 26 => 'applychangetags', 27 => 'spamblacklistlog', 28 => 'mwoauthmanagemygrants' ]
Whether the user is editing from mobile app (user_app)
false
Whether or not a user is editing through the mobile interface (user_mobile)
false
Page ID (page_id)
271968
Page namespace (page_namespace)
0
Page title without namespace (page_title)
'Mixin'
Full page title (page_prefixedtitle)
'Mixin'
Edit protection level of the page (page_restrictions_edit)
[]
Last ten users to contribute to the page (page_recent_contributors)
[ 0 => 'Mps', 1 => '51.9.195.162', 2 => 'Citation bot', 3 => '136.25.161.245', 4 => 'WikiCleanerBot', 5 => 'Yung Tamerlane', 6 => 'MCEmperor', 7 => 'Jarble', 8 => 'Brteja', 9 => 'ElaineHaight' ]
Page age in seconds (page_age)
591887294
Action (action)
'edit'
Edit summary/reason (summary)
'/* Interfaces and traits */ '
Old content model (old_content_model)
'wikitext'
New content model (new_content_model)
'wikitext'
Old page wikitext, before the edit (old_wikitext)
'{{about|the programming concept|the ice cream|Mix-in}} In [[object-oriented programming language]]s, a '''mixin''' (or '''mix-in''')<ref name=":0" /><ref name=":1" /><ref name=":2" /><ref name=":3" /> is a [[class (computer science)|class]] that contains methods for use by other classes without having to be the parent class of those other classes. How those other classes gain access to the mixin's methods depends on the language. Mixins are sometimes described as being "included" rather than "inherited". Mixins encourage [[code reuse]] and can be used to avoid the inheritance ambiguity that multiple inheritance can cause<ref>{{cite book|last=Boyland|first=John|title=ECOOP '96, Object-oriented Programming: 10th European Conference|publisher=Springer|isbn=9783540614395|pages=16–17|chapter-url=https://books.google.com/books?id=sGvtaGy8SJ8C&dq=pathologies+of+multiple+inheritance&pg=PA16|author2=Giuseppe Castagna|editor=Pierre Cointe|accessdate=17 January 2014|chapter=Type-Safe Compilation of Covariant Specialization: A Practical Case|date=26 June 1996}}</ref> (the "[[Multiple inheritance#The diamond problem|diamond problem]]"), or to work around lack of support for multiple inheritance in a language. A mixin can also be viewed as an [[Interface (object-oriented programming)|interface]] with implemented [[Method (computer science)|methods]]. This pattern is an example of enforcing the [[dependency inversion principle]]. ==History== Mixins first appeared in the [[Symbolics]]'s object-oriented [[Flavors (computer science)|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|Steve's Ice Cream Parlor]] in Somerville, Massachusetts:<ref name=":0">[http://www.linuxjournal.com/article/4540 Using Mix-ins with Python]</ref> 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.<ref name=":1">[http://listserv.linguistlist.org/cgi-bin/wa?A2=ind0208a&L=ads-l&P=11751 Mix-Ins (Steve's ice cream, Boston, 1975)] {{webarchive|url=https://web.archive.org/web/20071026043218/http://listserv.linguistlist.org/cgi-bin/wa?A2=ind0208a&L=ads-l&P=11751 |date=2007-10-26 }}</ref> ==Definition== Mixins are a language concept that allows a programmer to inject some code into a [[class (computer programming)|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.<ref>http://c2.com/cgi/wiki?MixIn</ref> A mixin class acts as the parent class, containing the desired functionality. A [[Subclass (computer science)|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 [[Subclass (computer science)|child class]], without creating a rigid, single "is a" relationship. Here lies the important difference between the concepts of mixins and [[Inheritance (object-oriented programming)|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. ==Advantages== # 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.<ref>{{Cite web|url=http://culttt.com/2015/07/08/working-with-mixins-in-ruby/|title=Working with Mixins in Ruby|date=8 July 2015}}</ref> # [[Code reuse|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.<ref>http://naildrivin5.com/blog/2012/12/19/re-use-in-oo-inheritance.html</ref> # Mixins allow inheritance and use of only the desired features from the parent class, not necessarily all of the features from the parent class.<ref>{{Cite web |url=http://justinleitgeb.com/ruby/moving-beyond-mixins/ |title=Archived copy |access-date=2015-09-16 |archive-url=https://web.archive.org/web/20150925090219/http://justinleitgeb.com/ruby/moving-beyond-mixins/ |archive-date=2015-09-25 |url-status=dead }}</ref> ==Implementations== 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 (programming language)|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 function]]s". 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: <code>:before</code> and <code>:after</code> daemons, whoppers and wrappers in Flavors. CLOS added <code>:around</code> methods and the ability to call shadowed methods via {{code|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 <code>:around</code> method. Both CLOS and Flavors allow the computed reuse via method combinations. <code>:before</code>, <code>:after</code> and <code>:around</code> methods are a feature of the standard method combination. Other method combinations are provided. An example is the <code>+</code> 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 <code>bordered-button</code> (that is both a graphical object and uses the <code>border</code> mixin) would compute its width by calling all applicable width methods—via the <code>+</code> method combination. All return values are added and create the combined width of the object. In an OOPSLA 90 paper,<ref>[http://www.bracha.org/oopsla90.pdf OOPSLA '90, Mixin based inheritance (pdf)]</ref> Gilad Bracha and William Cook reinterpret different inheritance mechanisms found in Smalltalk, Beta and CLOS as special forms of a mixin inheritance. ==Programming languages that use mixins== Other than Flavors and CLOS (a part of [[Common Lisp]]), some languages that use mixins are: *[[Ada (programming language)|Ada]] (by extending an existing tagged record with arbitrary operations in a generic) *[[C Sharp (programming language)|C#]] (since C# 8.0, by means of ''default methods'' of interfaces)<ref>{{Cite web |last=Bill Wagner |title=Create mixin types using default interface methods |url=https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/tutorials/mixins-with-default-interface-methods |access-date=2022-04-18 |website=docs.microsoft.com |language=en-us}}</ref> *[[Cobra (programming language)|Cobra]] *[[Adobe ColdFusion|ColdFusion]] (Class based using includes and Object based by assigning methods from one object to another at runtime) *[[Curl (programming language)|Curl]] (with Curl RTE) *[[D (programming language)|D]] (called [http://www.digitalmars.com/d/template-mixin.html "template mixins"]; D also includes a [http://dlang.org/mixin.html "mixin"] statement that compiles strings as code.) *[[Dart (programming language)|Dart]] *[[Factor programming language|Factor]]<ref>{{cite web | url = http://concatenative.org/wiki/view/Factor/Features/The%20language | title = Factor/Features/The language | author = slava | date = 2010-01-25 | publisher = [http://concatenative.org concatenative.org] | quote = Factor's main language features: … Object system with Inheritance, Generic functions, Predicate dispatch and ''Mixins'' | accessdate = 2012-05-15 }}</ref> *[[Groovy (programming language)|Groovy]] *[[Java (programming language)|Java]] (since Java 8, by means of ''default methods'' of interfaces) *[[JavaScript#Delegative|JavaScript Delegation - Functions as Roles (Traits and Mixins)]] *[[Kotlin (programming language)|Kotlin]] *[[Less (stylesheet_language)|Less]] *[[OCaml]]<ref>{{cite web | url = https://www.lexifi.com/blog/ocaml/mixin/ | title = Mixin objects | author = Alain Frisch | date = 2013-06-14 | publisher = LexiFi | accessdate = 2022-03-29 }}</ref> *[[Perl]] (through [[Moose_(Perl)#Roles|roles]] in the Moose extension of the Perl 5 object system) *[[PHP]]'s "[[Trait (computer programming)|traits]]" *[[Magik (programming language)|Magik]] *[[MATLAB]]<ref>{{Cite web|url=https://in.mathworks.com/help/matlab/mixin-classes.html|title = Classes - MATLAB & Simulink - MathWorks India}}</ref> *[[Python (programming language)|Python]] *[[Racket (programming language)|Racket]] ([http://docs.racket-lang.org/guide/classes.html#(part._.Mixins) mixins documentation]) *[[Raku (programming language)|Raku]] *[[Ruby (programming language)|Ruby]] *[[Rust (programming language)|Rust]] *[[Scala (programming language)|Scala]]<ref>{{cite web |url=http://docs.scala-lang.org/tutorials/tour/mixin-class-composition.html | title=Mixin Class Composition |publisher=[[École polytechnique fédérale de Lausanne]] |accessdate=16 May 2014}}</ref> *[[XOTcl]]/[http://wiki.tcl.tk/18152 TclOO] (object systems builtin to [[Tcl]])<ref>[http://media.wu-wien.ac.at/doc/tutorial.html#mixins Mixin classes in XOTcl]</ref> * [[Sass (stylesheet language) |Sass (A stylesheet language)]] *[[Smalltalk]] *[[Vala (programming language)|Vala]] *[[Swift (programming language)|Swift]] *[[SystemVerilog]] *[[TypeScript]] ([https://www.typescriptlang.org/docs/handbook/mixins.html mixins documentation]) 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 [[static typing|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. ==Examples== ===In Common Lisp=== [[Common Lisp]] provides mixins in CLOS (Common Lisp Object System) similar to Flavors. <code>object-width</code> is a generic function with one argument that uses the <code>+</code> method combination. This combination determines that all applicable methods for a generic function will be called and the results will be added. <syntaxhighlight lang="lisp"> (defgeneric object-width (object) (:method-combination +)) </syntaxhighlight> <code>button</code> is a class with one slot for the button text. <syntaxhighlight lang="lisp"> (defclass button () ((text :initform "click me"))) </syntaxhighlight> There is a method for objects of class button that computes the width based on the length of the button text. <code>+</code> is the method qualifier for the method combination of the same name. <syntaxhighlight lang="lisp"> (defmethod object-width + ((object button)) (* 10 (length (slot-value object 'text)))) </syntaxhighlight> A <code>border-mixin</code> class. The naming is just a convention. There are no superclasses, and no slots. <syntaxhighlight lang="lisp"> (defclass border-mixin () ()) </syntaxhighlight> There is a method computing the width of the border. Here it is just 4. <syntaxhighlight lang="lisp"> (defmethod object-width + ((object border-mixin)) 4) </syntaxhighlight> <code>bordered-button</code> is a class inheriting from both <code>border-mixin</code> and <code>button</code>. <syntaxhighlight lang="lisp"> (defclass bordered-button (border-mixin button) ()) </syntaxhighlight> We can now compute the width of a button. Calling <code>object-width</code> computes 80. The result is the result of the single applicable method: the method <code>object-width</code> for the class <code>button</code>. <syntaxhighlight lang="lisp"> ? (object-width (make-instance 'button)) 80 </syntaxhighlight> We can also compute the width of a <code>bordered-button</code>. Calling <code>object-width</code> computes 84. The result is the sum of the results of the two applicable methods: the method <code>object-width</code> for the class <code>button</code> and the method <code>object-width</code> for the class <code>border-mixin</code>. <syntaxhighlight lang="lisp"> ? (object-width (make-instance 'bordered-button)) 84 </syntaxhighlight> ===In Python=== In [[Python (programming language)|Python]], an example of the mixin concept is found in the <code>SocketServer</code> module,<ref>[https://hg.python.org/cpython/file/3.5/Lib/socketserver.py Source code for SocketServer in CPython 3.5]</ref> which has both a <code>UDPServer</code> class and a <code>TCPServer</code> class. They act as servers for [[User Datagram Protocol|UDP]] and [[Transmission Control Protocol|TCP]] socket servers, respectively. Additionally, there are two mixin classes: <code>ForkingMixIn</code> and <code>ThreadingMixIn</code>. Normally, all new connections are handled within the same process. By extending <code>TCPServer</code> with the <code>ThreadingMixIn</code> as follows: <syntaxhighlight lang="python"> class ThreadingTCPServer(ThreadingMixIn, TCPServer): pass </syntaxhighlight> the <code>ThreadingMixIn</code> class adds functionality to the TCP server such that each new connection creates a new [[thread (computer science)|thread]]. Using the same method, a <code>ThreadingUDPServer</code> can be created without having to duplicate the code in <code>ThreadingMixIn</code>. Alternatively, using the <code>ForkingMixIn</code> would cause the process to be [[fork (operating system)|forked]] for each new connection. Clearly, the functionality to create a new thread or fork a process is not terribly useful as a stand-alone class. In this usage example, the mixins provide alternative underlying functionality without affecting the functionality as a socket server. ===In Ruby=== Most of the Ruby world is based around mixins via <code>Modules</code>. The concept of mixins is implemented in Ruby by the keyword <code>include</code> to which we pass the name of the module as [[Parameter (computer programming)|parameter]]. Example: <syntaxhighlight lang="ruby"> class Student include Comparable # The class Student inherits the Comparable module using the 'include' keyword attr_accessor :name, :score def initialize(name, score) @name = name @score = score end # Including the Comparable module requires the implementing class to define the <=> comparison operator # Here's the comparison operator. We compare 2 student instances based on their scores. def <=>(other) @score <=> other.score end # Here's the good bit - I get access to <, <=, >,>= and other methods of the Comparable Interface for free. end s1 = Student.new("Peter", 100) s2 = Student.new("Jason", 90) s1 > s2 #true s1 <= s2 #false </syntaxhighlight> ===In JavaScript=== '''The ''Object-Literal and <code>extend</code> Approach''''' It is technically possible to add behavior to an object by binding functions to keys in the object. However, this lack of separation between state and behavior has drawbacks: # It intermingles properties of the model domain with that of implementation domain. # No sharing of common behavior. Metaobjects solve this problem by separating the domain specific properties of objects from their behaviour specific properties.<ref>{{Cite web|url=http://raganwald.com/2014/04/10/mixins-forwarding-delegation.html|title = Mixins, Forwarding, and Delegation in JavaScript}}</ref> An extend function is used to mix the behavior in:<ref>{{Cite web |url=http://bob.yexley.net/dry-javascript-with-mixins/ |title=Archived copy |access-date=2015-09-16 |archive-url=https://web.archive.org/web/20150921074320/http://bob.yexley.net/dry-javascript-with-mixins/ |archive-date=2015-09-21 |url-status=dead }}</ref> <syntaxhighlight lang="javascript"> 'use strict'; const Halfling = function (fName, lName) { this.firstName = fName; this.lastName = lName; }; const mixin = { fullName() { return this.firstName + ' ' + this.lastName; }, rename(first, last) { this.firstName = first; this.lastName = last; return this; } }; // An extend function const extend = (obj, mixin) => { Object.keys(mixin).forEach(key => obj[key] = mixin[key]); return obj; }; const sam = new Halfling('Sam', 'Loawry'); const frodo = new Halfling('Freeda', 'Baggs'); // Mixin the other methods extend(Halfling.prototype, mixin); console.log(sam.fullName()); // Sam Loawry console.log(frodo.fullName()); // Freeda Baggs sam.rename('Samwise', 'Gamgee'); frodo.rename('Frodo', 'Baggins'); console.log(sam.fullName()); // Samwise Gamgee console.log(frodo.fullName()); // Frodo Baggins </syntaxhighlight> '''Mixin with using Object.assign()''' <syntaxhighlight lang="javascript"> 'use strict'; // Creating an object const obj1 = { name: 'Marcus Aurelius', city: 'Rome', born: '121-04-26' }; // Mixin 1 const mix1 = { toString() { return `${this.name} was born in ${this.city} in ${this.born}`; }, age() { const year = new Date().getFullYear(); const born = new Date(this.born).getFullYear(); return year - born; } }; // Mixin 2 const mix2 = { toString() { return `${this.name} - ${this.city} - ${this.born}`; } }; // Adding the methods from mixins to the object using Object.assign() Object.assign(obj1, mix1, mix2); console.log(obj1.toString()); // Marcus Aurelius - Rome - 121-04-26 console.log(`His age is ${obj1.age()} as of today`); // His age is 1897 as of today </syntaxhighlight> '''The pure function and delegation based ''Flight-Mixin Approach''''' Even though the firstly described approach is mostly widespread the next one is closer to what JavaScript's language core fundamentally offers - [[JavaScript#Delegative|Delegation]]. Two function object based patterns already do the trick without the need of a third party's implementation of <code>extend</code>. <syntaxhighlight lang="javascript"> 'use strict'; // Implementation const EnumerableFirstLast = (function () { // function based module pattern. const first = function () { return this[0]; }, last = function () { return this[this.length - 1]; }; return function () { // function based Flight-Mixin mechanics ... this.first = first; // ... referring to ... this.last = last; // ... shared code. }; }()); // Application - explicit delegation: // applying [first] and [last] enumerable behavior onto [Array]'s [prototype]. EnumerableFirstLast.call(Array.prototype); // Now you can do: const a = [1, 2, 3]; a.first(); // 1 a.last(); // 3 </syntaxhighlight> ===In other languages=== In the [[Curl (programming language)|Curl]] web-content language, multiple inheritance is used as classes with no instances may implement methods. Common mixins include all skinnable <code>ControlUI</code>s inheriting from <code>SkinnableControlUI</code>, user interface delegate objects that require dropdown menus inheriting from StandardBaseDropdownUI and such explicitly named mixin classes as <code>FontGraphicMixin</code>, <code>FontVisualMixin</code> and <code>NumericAxisMixin-of</code> class. Version 7.0 added library access so that mixins do not need to be in the same package or be public abstract. Curl constructors are factories that facilitates using multiple-inheritance without explicit declaration of either interfaces or mixins.{{Citation needed|date=May 2009}} ==Interfaces and traits== Java 8 introduces a new feature in the form of default methods for interfaces.<ref>{{Cite web|url=https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html|title = Default Methods (The Java™ Tutorials > Learning the Java Language > Interfaces and Inheritance)}}</ref> 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 adds a possibility of applying the concept in a mixin sort of a way. 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 C# 3.0 came the introduction of extension methods and they can be applied, not only to classes 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.<ref name=":2">[http://www.zorched.net/2008/01/03/implementing-mixins-with-c-extension-methods/ Implementing Mix-ins with C# Extension Methods]</ref><ref name=":3">[http://blogs.msdn.com/abhinaba/archive/2006/01/06/510034.aspx I know the answer (it's 42) : Mix-ins and C#]</ref><ref>[http://erwyn.bloggingabout.net/2005/10/20/mixins-generics-and-extension-methods-in-c/ Mixins, generics and extension methods in C#]</ref> C# 8.0 adds the feature of default interface methods.<ref>[https://docs.microsoft.com/en-us/dotnet/csharp/tutorials/mixins-with-default-interface-methods Mix functionality in when creating classes using interfaces with default interface methods]</ref> [[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<ref>[http://peterseliger.blogspot.de/2014/04/the-many-talents-of-javascript.html#the-many-talents-of-javascript-for-generalizing-role-oriented-programming-approaches-like-traits-and-mixins The many talents of JavaScript for generalizing Role Oriented Programming approaches like Traits and Mixins], April 11, 2014.</ref> supports [[Trait (computer programming)|Trait]] and mixin<ref>Angus Croll, [http://javascriptweblog.wordpress.com/2011/05/31/a-fresh-look-at-javascript-mixins/ A fresh look at JavaScript Mixins], published May 31, 2011.</ref><ref>[https://github.com/petsel/javascript-code-reuse-patterns/tree/master/source/components/composition/ JavaScript Code Reuse Patterns], April 19, 2013.</ref> based object composition via function objects that implement additional behavior and then are delegated via <code>call</code> or <code>apply</code> to objects that are in need of such new functionality. ===In Scala=== Scala has a rich type system and Traits are a part of it which helps implement mixin behaviour. As their name reveals, Traits are usually used to represent a distinct feature or aspect that is normally orthogonal to the responsibility of a concrete type or at least of a certain instance.<ref>{{Cite web|url=https://gleichmann.wordpress.com/2009/07/19/scala-in-practice-traits-as-mixins-motivation|title = Scala in practice: Traits as Mixins – Motivation|date = 19 July 2009}}</ref> For example, the ability to sing is modeled as such an orthogonal feature: it could be applied to Birds, Persons, etc. <syntaxhighlight lang="scala"> trait Singer{ def sing { println(" singing … ") } //more methods } class Bird extends Singer </syntaxhighlight> Here, Bird has mixed in all methods of the trait into its own definition as if class Bird had defined method sing() on its own. As <code>extends</code> is also used to inherit from a super class, in case of a trait <code>extends</code> is used if no super class is inherited and only for mixin in the first trait. All following traits are mixed in using keyword <code>with</code>. <syntaxhighlight lang="scala"> class Person class Actor extends Person with Singer class Actor extends Singer with Performer </syntaxhighlight> Scala allows mixing in a trait (creating an [[anonymous type]]) when creating a new instance of a class. In the case of a Person class instance, not all instances can sing. This feature comes use then: <syntaxhighlight lang="scala"> class Person{ def tell { println (" Human ") } //more methods } val singingPerson = new Person with Singer singingPerson.sing </syntaxhighlight> ===In Swift=== Mixin can be achieved in Swift by using a language feature called Default implementation in Protocol Extension. <syntaxhighlight lang="swift" line="1"> 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.") } } </syntaxhighlight> ==See also== * [[Abstract type]] * [[Decorator pattern]] * [[Policy-based design]] * [[Trait (computer programming)|Trait]], a similar structure that doesn't require linear composition ==References== {{Reflist|30em}} ==External links== * [http://c2.com/cgi/wiki?MixIn MixIn] at Portland Pattern Repository * [https://web.archive.org/web/20050308114937/http://www.macromedia.com/support/documentation/en/flex/1/mixin/index.html Mixins] in [[ActionScript]] * [https://www.dreamsongs.com/Files/ECOOP.pdf 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. <!--Categories--> [[Category:Object-oriented programming languages]]'
New page wikitext, after the edit (new_wikitext)
'{{about|the programming concept|the ice cream|Mix-in}} In [[object-oriented programming language]]s, a '''mixin''' (or '''mix-in''')<ref name=":0" /><ref name=":1" /><ref name=":2" /><ref name=":3" /> is a [[class (computer science)|class]] that contains methods for use by other classes without having to be the parent class of those other classes. How those other classes gain access to the mixin's methods depends on the language. Mixins are sometimes described as being "included" rather than "inherited". Mixins encourage [[code reuse]] and can be used to avoid the inheritance ambiguity that multiple inheritance can cause<ref>{{cite book|last=Boyland|first=John|title=ECOOP '96, Object-oriented Programming: 10th European Conference|publisher=Springer|isbn=9783540614395|pages=16–17|chapter-url=https://books.google.com/books?id=sGvtaGy8SJ8C&dq=pathologies+of+multiple+inheritance&pg=PA16|author2=Giuseppe Castagna|editor=Pierre Cointe|accessdate=17 January 2014|chapter=Type-Safe Compilation of Covariant Specialization: A Practical Case|date=26 June 1996}}</ref> (the "[[Multiple inheritance#The diamond problem|diamond problem]]"), or to work around lack of support for multiple inheritance in a language. A mixin can also be viewed as an [[Interface (object-oriented programming)|interface]] with implemented [[Method (computer science)|methods]]. This pattern is an example of enforcing the [[dependency inversion principle]]. ==History== Mixins first appeared in the [[Symbolics]]'s object-oriented [[Flavors (computer science)|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|Steve's Ice Cream Parlor]] in Somerville, Massachusetts:<ref name=":0">[http://www.linuxjournal.com/article/4540 Using Mix-ins with Python]</ref> 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.<ref name=":1">[http://listserv.linguistlist.org/cgi-bin/wa?A2=ind0208a&L=ads-l&P=11751 Mix-Ins (Steve's ice cream, Boston, 1975)] {{webarchive|url=https://web.archive.org/web/20071026043218/http://listserv.linguistlist.org/cgi-bin/wa?A2=ind0208a&L=ads-l&P=11751 |date=2007-10-26 }}</ref> ==Definition== Mixins are a language concept that allows a programmer to inject some code into a [[class (computer programming)|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.<ref>http://c2.com/cgi/wiki?MixIn</ref> A mixin class acts as the parent class, containing the desired functionality. A [[Subclass (computer science)|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 [[Subclass (computer science)|child class]], without creating a rigid, single "is a" relationship. Here lies the important difference between the concepts of mixins and [[Inheritance (object-oriented programming)|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. ==Advantages== # 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.<ref>{{Cite web|url=http://culttt.com/2015/07/08/working-with-mixins-in-ruby/|title=Working with Mixins in Ruby|date=8 July 2015}}</ref> # [[Code reuse|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.<ref>http://naildrivin5.com/blog/2012/12/19/re-use-in-oo-inheritance.html</ref> # Mixins allow inheritance and use of only the desired features from the parent class, not necessarily all of the features from the parent class.<ref>{{Cite web |url=http://justinleitgeb.com/ruby/moving-beyond-mixins/ |title=Archived copy |access-date=2015-09-16 |archive-url=https://web.archive.org/web/20150925090219/http://justinleitgeb.com/ruby/moving-beyond-mixins/ |archive-date=2015-09-25 |url-status=dead }}</ref> ==Implementations== 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 (programming language)|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 function]]s". 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: <code>:before</code> and <code>:after</code> daemons, whoppers and wrappers in Flavors. CLOS added <code>:around</code> methods and the ability to call shadowed methods via {{code|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 <code>:around</code> method. Both CLOS and Flavors allow the computed reuse via method combinations. <code>:before</code>, <code>:after</code> and <code>:around</code> methods are a feature of the standard method combination. Other method combinations are provided. An example is the <code>+</code> 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 <code>bordered-button</code> (that is both a graphical object and uses the <code>border</code> mixin) would compute its width by calling all applicable width methods—via the <code>+</code> method combination. All return values are added and create the combined width of the object. In an OOPSLA 90 paper,<ref>[http://www.bracha.org/oopsla90.pdf OOPSLA '90, Mixin based inheritance (pdf)]</ref> Gilad Bracha and William Cook reinterpret different inheritance mechanisms found in Smalltalk, Beta and CLOS as special forms of a mixin inheritance. ==Programming languages that use mixins== Other than Flavors and CLOS (a part of [[Common Lisp]]), some languages that use mixins are: *[[Ada (programming language)|Ada]] (by extending an existing tagged record with arbitrary operations in a generic) *[[C Sharp (programming language)|C#]] (since C# 8.0, by means of ''default methods'' of interfaces)<ref>{{Cite web |last=Bill Wagner |title=Create mixin types using default interface methods |url=https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/tutorials/mixins-with-default-interface-methods |access-date=2022-04-18 |website=docs.microsoft.com |language=en-us}}</ref> *[[Cobra (programming language)|Cobra]] *[[Adobe ColdFusion|ColdFusion]] (Class based using includes and Object based by assigning methods from one object to another at runtime) *[[Curl (programming language)|Curl]] (with Curl RTE) *[[D (programming language)|D]] (called [http://www.digitalmars.com/d/template-mixin.html "template mixins"]; D also includes a [http://dlang.org/mixin.html "mixin"] statement that compiles strings as code.) *[[Dart (programming language)|Dart]] *[[Factor programming language|Factor]]<ref>{{cite web | url = http://concatenative.org/wiki/view/Factor/Features/The%20language | title = Factor/Features/The language | author = slava | date = 2010-01-25 | publisher = [http://concatenative.org concatenative.org] | quote = Factor's main language features: … Object system with Inheritance, Generic functions, Predicate dispatch and ''Mixins'' | accessdate = 2012-05-15 }}</ref> *[[Groovy (programming language)|Groovy]] *[[Java (programming language)|Java]] (since Java 8, by means of ''default methods'' of interfaces) *[[JavaScript#Delegative|JavaScript Delegation - Functions as Roles (Traits and Mixins)]] *[[Kotlin (programming language)|Kotlin]] *[[Less (stylesheet_language)|Less]] *[[OCaml]]<ref>{{cite web | url = https://www.lexifi.com/blog/ocaml/mixin/ | title = Mixin objects | author = Alain Frisch | date = 2013-06-14 | publisher = LexiFi | accessdate = 2022-03-29 }}</ref> *[[Perl]] (through [[Moose_(Perl)#Roles|roles]] in the Moose extension of the Perl 5 object system) *[[PHP]]'s "[[Trait (computer programming)|traits]]" *[[Magik (programming language)|Magik]] *[[MATLAB]]<ref>{{Cite web|url=https://in.mathworks.com/help/matlab/mixin-classes.html|title = Classes - MATLAB & Simulink - MathWorks India}}</ref> *[[Python (programming language)|Python]] *[[Racket (programming language)|Racket]] ([http://docs.racket-lang.org/guide/classes.html#(part._.Mixins) mixins documentation]) *[[Raku (programming language)|Raku]] *[[Rust (programming language)|Rust]] *[[<ref>Traits in Rust</ref>https://doc.rust-lang.org/book/ch10-02-traits.html (programming language)|Rust]] *[[Ruby (programming language)|Ruby]] *[[Scala (programming language)|Scala]]<ref>{{cite web |url=http://docs.scala-lang.org/tutorials/tour/mixin-class-composition.html | title=Mixin Class Composition |publisher=[[École polytechnique fédérale de Lausanne]] |accessdate=16 May 2014}}</ref> *[[XOTcl]]/[http://wiki.tcl.tk/18152 TclOO] (object systems builtin to [[Tcl]])<ref>[http://media.wu-wien.ac.at/doc/tutorial.html#mixins Mixin classes in XOTcl]</ref> * [[Sass (stylesheet language) |Sass (A stylesheet language)]] *[[Smalltalk]] *[[Vala (programming language)|Vala]] *[[Swift (programming language)|Swift]] *[[SystemVerilog]] *[[TypeScript]] ([https://www.typescriptlang.org/docs/handbook/mixins.html mixins documentation]) 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 [[static typing|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. ==Examples== ===In Common Lisp=== [[Common Lisp]] provides mixins in CLOS (Common Lisp Object System) similar to Flavors. <code>object-width</code> is a generic function with one argument that uses the <code>+</code> method combination. This combination determines that all applicable methods for a generic function will be called and the results will be added. <syntaxhighlight lang="lisp"> (defgeneric object-width (object) (:method-combination +)) </syntaxhighlight> <code>button</code> is a class with one slot for the button text. <syntaxhighlight lang="lisp"> (defclass button () ((text :initform "click me"))) </syntaxhighlight> There is a method for objects of class button that computes the width based on the length of the button text. <code>+</code> is the method qualifier for the method combination of the same name. <syntaxhighlight lang="lisp"> (defmethod object-width + ((object button)) (* 10 (length (slot-value object 'text)))) </syntaxhighlight> A <code>border-mixin</code> class. The naming is just a convention. There are no superclasses, and no slots. <syntaxhighlight lang="lisp"> (defclass border-mixin () ()) </syntaxhighlight> There is a method computing the width of the border. Here it is just 4. <syntaxhighlight lang="lisp"> (defmethod object-width + ((object border-mixin)) 4) </syntaxhighlight> <code>bordered-button</code> is a class inheriting from both <code>border-mixin</code> and <code>button</code>. <syntaxhighlight lang="lisp"> (defclass bordered-button (border-mixin button) ()) </syntaxhighlight> We can now compute the width of a button. Calling <code>object-width</code> computes 80. The result is the result of the single applicable method: the method <code>object-width</code> for the class <code>button</code>. <syntaxhighlight lang="lisp"> ? (object-width (make-instance 'button)) 80 </syntaxhighlight> We can also compute the width of a <code>bordered-button</code>. Calling <code>object-width</code> computes 84. The result is the sum of the results of the two applicable methods: the method <code>object-width</code> for the class <code>button</code> and the method <code>object-width</code> for the class <code>border-mixin</code>. <syntaxhighlight lang="lisp"> ? (object-width (make-instance 'bordered-button)) 84 </syntaxhighlight> ===In Python=== In [[Python (programming language)|Python]], an example of the mixin concept is found in the <code>SocketServer</code> module,<ref>[https://hg.python.org/cpython/file/3.5/Lib/socketserver.py Source code for SocketServer in CPython 3.5]</ref> which has both a <code>UDPServer</code> class and a <code>TCPServer</code> class. They act as servers for [[User Datagram Protocol|UDP]] and [[Transmission Control Protocol|TCP]] socket servers, respectively. Additionally, there are two mixin classes: <code>ForkingMixIn</code> and <code>ThreadingMixIn</code>. Normally, all new connections are handled within the same process. By extending <code>TCPServer</code> with the <code>ThreadingMixIn</code> as follows: <syntaxhighlight lang="python"> class ThreadingTCPServer(ThreadingMixIn, TCPServer): pass </syntaxhighlight> the <code>ThreadingMixIn</code> class adds functionality to the TCP server such that each new connection creates a new [[thread (computer science)|thread]]. Using the same method, a <code>ThreadingUDPServer</code> can be created without having to duplicate the code in <code>ThreadingMixIn</code>. Alternatively, using the <code>ForkingMixIn</code> would cause the process to be [[fork (operating system)|forked]] for each new connection. Clearly, the functionality to create a new thread or fork a process is not terribly useful as a stand-alone class. In this usage example, the mixins provide alternative underlying functionality without affecting the functionality as a socket server. ===In Ruby=== Most of the Ruby world is based around mixins via <code>Modules</code>. The concept of mixins is implemented in Ruby by the keyword <code>include</code> to which we pass the name of the module as [[Parameter (computer programming)|parameter]]. Example: <syntaxhighlight lang="ruby"> class Student include Comparable # The class Student inherits the Comparable module using the 'include' keyword attr_accessor :name, :score def initialize(name, score) @name = name @score = score end # Including the Comparable module requires the implementing class to define the <=> comparison operator # Here's the comparison operator. We compare 2 student instances based on their scores. def <=>(other) @score <=> other.score end # Here's the good bit - I get access to <, <=, >,>= and other methods of the Comparable Interface for free. end s1 = Student.new("Peter", 100) s2 = Student.new("Jason", 90) s1 > s2 #true s1 <= s2 #false </syntaxhighlight> ===In JavaScript=== '''The ''Object-Literal and <code>extend</code> Approach''''' It is technically possible to add behavior to an object by binding functions to keys in the object. However, this lack of separation between state and behavior has drawbacks: # It intermingles properties of the model domain with that of implementation domain. # No sharing of common behavior. Metaobjects solve this problem by separating the domain specific properties of objects from their behaviour specific properties.<ref>{{Cite web|url=http://raganwald.com/2014/04/10/mixins-forwarding-delegation.html|title = Mixins, Forwarding, and Delegation in JavaScript}}</ref> An extend function is used to mix the behavior in:<ref>{{Cite web |url=http://bob.yexley.net/dry-javascript-with-mixins/ |title=Archived copy |access-date=2015-09-16 |archive-url=https://web.archive.org/web/20150921074320/http://bob.yexley.net/dry-javascript-with-mixins/ |archive-date=2015-09-21 |url-status=dead }}</ref> <syntaxhighlight lang="javascript"> 'use strict'; const Halfling = function (fName, lName) { this.firstName = fName; this.lastName = lName; }; const mixin = { fullName() { return this.firstName + ' ' + this.lastName; }, rename(first, last) { this.firstName = first; this.lastName = last; return this; } }; // An extend function const extend = (obj, mixin) => { Object.keys(mixin).forEach(key => obj[key] = mixin[key]); return obj; }; const sam = new Halfling('Sam', 'Loawry'); const frodo = new Halfling('Freeda', 'Baggs'); // Mixin the other methods extend(Halfling.prototype, mixin); console.log(sam.fullName()); // Sam Loawry console.log(frodo.fullName()); // Freeda Baggs sam.rename('Samwise', 'Gamgee'); frodo.rename('Frodo', 'Baggins'); console.log(sam.fullName()); // Samwise Gamgee console.log(frodo.fullName()); // Frodo Baggins </syntaxhighlight> '''Mixin with using Object.assign()''' <syntaxhighlight lang="javascript"> 'use strict'; // Creating an object const obj1 = { name: 'Marcus Aurelius', city: 'Rome', born: '121-04-26' }; // Mixin 1 const mix1 = { toString() { return `${this.name} was born in ${this.city} in ${this.born}`; }, age() { const year = new Date().getFullYear(); const born = new Date(this.born).getFullYear(); return year - born; } }; // Mixin 2 const mix2 = { toString() { return `${this.name} - ${this.city} - ${this.born}`; } }; // Adding the methods from mixins to the object using Object.assign() Object.assign(obj1, mix1, mix2); console.log(obj1.toString()); // Marcus Aurelius - Rome - 121-04-26 console.log(`His age is ${obj1.age()} as of today`); // His age is 1897 as of today </syntaxhighlight> '''The pure function and delegation based ''Flight-Mixin Approach''''' Even though the firstly described approach is mostly widespread the next one is closer to what JavaScript's language core fundamentally offers - [[JavaScript#Delegative|Delegation]]. Two function object based patterns already do the trick without the need of a third party's implementation of <code>extend</code>. <syntaxhighlight lang="javascript"> 'use strict'; // Implementation const EnumerableFirstLast = (function () { // function based module pattern. const first = function () { return this[0]; }, last = function () { return this[this.length - 1]; }; return function () { // function based Flight-Mixin mechanics ... this.first = first; // ... referring to ... this.last = last; // ... shared code. }; }()); // Application - explicit delegation: // applying [first] and [last] enumerable behavior onto [Array]'s [prototype]. EnumerableFirstLast.call(Array.prototype); // Now you can do: const a = [1, 2, 3]; a.first(); // 1 a.last(); // 3 </syntaxhighlight> ===In other languages=== In the [[Curl (programming language)|Curl]] web-content language, multiple inheritance is used as classes with no instances may implement methods. Common mixins include all skinnable <code>ControlUI</code>s inheriting from <code>SkinnableControlUI</code>, user interface delegate objects that require dropdown menus inheriting from StandardBaseDropdownUI and such explicitly named mixin classes as <code>FontGraphicMixin</code>, <code>FontVisualMixin</code> and <code>NumericAxisMixin-of</code> class. Version 7.0 added library access so that mixins do not need to be in the same package or be public abstract. Curl constructors are factories that facilitates using multiple-inheritance without explicit declaration of either interfaces or mixins.{{Citation needed|date=May 2009}} ==Interfaces and traits== Java 8 introduces a new feature in the form of default methods for interfaces.<ref>{{Cite web|url=https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html|title = Default Methods (The Java™ Tutorials > Learning the Java Language > Interfaces and Inheritance)}}</ref> 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 adds a possibility of applying the concept in a mixin sort of a way. 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 C# 3.0 came the introduction of extension methods and they can be applied, not only to classes 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.<ref name=":2">[http://www.zorched.net/2008/01/03/implementing-mixins-with-c-extension-methods/ Implementing Mix-ins with C# Extension Methods]</ref><ref name=":3">[http://blogs.msdn.com/abhinaba/archive/2006/01/06/510034.aspx I know the answer (it's 42) : Mix-ins and C#]</ref><ref>[http://erwyn.bloggingabout.net/2005/10/20/mixins-generics-and-extension-methods-in-c/ Mixins, generics and extension methods in C#]</ref> C# 8.0 adds the feature of default interface methods.<ref>[https://docs.microsoft.com/en-us/dotnet/csharp/tutorials/mixins-with-default-interface-methods Mix functionality in when creating classes using interfaces with default interface methods]</ref> [[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<ref>[http://peterseliger.blogspot.de/2014/04/the-many-talents-of-javascript.html#the-many-talents-of-javascript-for-generalizing-role-oriented-programming-approaches-like-traits-and-mixins The many talents of JavaScript for generalizing Role Oriented Programming approaches like Traits and Mixins], April 11, 2014.</ref> supports [[Trait (computer programming)|Trait]] and mixin<ref>Angus Croll, [http://javascriptweblog.wordpress.com/2011/05/31/a-fresh-look-at-javascript-mixins/ A fresh look at JavaScript Mixins], published May 31, 2011.</ref><ref>[https://github.com/petsel/javascript-code-reuse-patterns/tree/master/source/components/composition/ JavaScript Code Reuse Patterns], April 19, 2013.</ref> based object composition via function objects that implement additional behavior and then are delegated via <code>call</code> or <code>apply</code> to objects that are in need of such new functionality. ===In Scala=== Scala has a rich type system and Traits are a part of it which helps implement mixin behaviour. As their name reveals, Traits are usually used to represent a distinct feature or aspect that is normally orthogonal to the responsibility of a concrete type or at least of a certain instance.<ref>{{Cite web|url=https://gleichmann.wordpress.com/2009/07/19/scala-in-practice-traits-as-mixins-motivation|title = Scala in practice: Traits as Mixins – Motivation|date = 19 July 2009}}</ref> For example, the ability to sing is modeled as such an orthogonal feature: it could be applied to Birds, Persons, etc. <syntaxhighlight lang="scala"> trait Singer{ def sing { println(" singing … ") } //more methods } class Bird extends Singer </syntaxhighlight> Here, Bird has mixed in all methods of the trait into its own definition as if class Bird had defined method sing() on its own. As <code>extends</code> is also used to inherit from a super class, in case of a trait <code>extends</code> is used if no super class is inherited and only for mixin in the first trait. All following traits are mixed in using keyword <code>with</code>. <syntaxhighlight lang="scala"> class Person class Actor extends Person with Singer class Actor extends Singer with Performer </syntaxhighlight> Scala allows mixing in a trait (creating an [[anonymous type]]) when creating a new instance of a class. In the case of a Person class instance, not all instances can sing. This feature comes use then: <syntaxhighlight lang="scala"> class Person{ def tell { println (" Human ") } //more methods } val singingPerson = new Person with Singer singingPerson.sing </syntaxhighlight> === In Rust === Rust makes extensive use of mixins via ''traits''. Traits, like in Scala, allow user to implement certain behaviour for a defined type. They are also used for [[Generic programming|generics]] and [[dynamic dispatch]], which allow for types with same traits to be used interchangeably statically or dynamically at runtime respectively. <syntaxhighlight lang="rust"> // Allows for types to "speak" trait Speak { fn speak(); // Rust allows implementors<ref><ref><ref><ref><ref><ref><ref><ref><ref></ref></ref></ref></ref></ref></ref></ref></ref></ref> to define default implementations for functions defined in traits fn great() { println!("Hi!") } } struct Robot; impl Speak for Robot { fn speak() { println!("Beep beep boop boop"); } } struct Dog; impl Speak for Dog { fn speak() { println!("Woof woof"); } // Here we override the definition of Speak::great on Dog fn great() { println!("Robot says howdy!") } } </syntaxhighlight> ===In Swift=== Mixin can be achieved in Swift by using a language feature called Default implementation in Protocol Extension. <syntaxhighlight lang="swift" line="1"> 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.") } } </syntaxhighlight> ==See also== * [[Abstract type]] * [[Decorator pattern]] * [[Policy-based design]] * [[Trait (computer programming)|Trait]], a similar structure that doesn't require linear composition ==References== {{Reflist|30em}} ==External links== * [http://c2.com/cgi/wiki?MixIn MixIn] at Portland Pattern Repository * [https://web.archive.org/web/20050308114937/http://www.macromedia.com/support/documentation/en/flex/1/mixin/index.html Mixins] in [[ActionScript]] * [https://www.dreamsongs.com/Files/ECOOP.pdf 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. <!--Categories--> [[Category:Object-oriented programming languages]]'
Unified diff of changes made by edit (edit_diff)
'@@ -70,6 +70,7 @@ *[[Racket (programming language)|Racket]] ([http://docs.racket-lang.org/guide/classes.html#(part._.Mixins) mixins documentation]) *[[Raku (programming language)|Raku]] +*[[Rust (programming language)|Rust]] +*[[<ref>Traits in Rust</ref>https://doc.rust-lang.org/book/ch10-02-traits.html (programming language)|Rust]] *[[Ruby (programming language)|Ruby]] -*[[Rust (programming language)|Rust]] *[[Scala (programming language)|Scala]]<ref>{{cite web |url=http://docs.scala-lang.org/tutorials/tour/mixin-class-composition.html | title=Mixin Class Composition |publisher=[[École polytechnique fédérale de Lausanne]] |accessdate=16 May 2014}}</ref> *[[XOTcl]]/[http://wiki.tcl.tk/18152 TclOO] (object systems builtin to [[Tcl]])<ref>[http://media.wu-wien.ac.at/doc/tutorial.html#mixins Mixin classes in XOTcl]</ref> @@ -355,4 +356,40 @@ val singingPerson = new Person with Singer singingPerson.sing +</syntaxhighlight> + +=== In Rust === +Rust makes extensive use of mixins via ''traits''. Traits, like in Scala, allow user to implement certain behaviour for a defined type. They are also used for [[Generic programming|generics]] and [[dynamic dispatch]], which allow for types with same traits to be used interchangeably statically or dynamically at runtime respectively. + +<syntaxhighlight lang="rust"> +// Allows for types to "speak" +trait Speak { + fn speak(); + + // Rust allows implementors<ref><ref><ref><ref><ref><ref><ref><ref><ref></ref></ref></ref></ref></ref></ref></ref></ref></ref> to define default implementations for functions defined in traits + fn great() { + println!("Hi!") + } +} + +struct Robot; + +impl Speak for Robot { + fn speak() { + println!("Beep beep boop boop"); + } +} + +struct Dog; + +impl Speak for Dog { + fn speak() { + println!("Woof woof"); + } + + // Here we override the definition of Speak::great on Dog + fn great() { + println!("Robot says howdy!") + } +} </syntaxhighlight> '
New page size (new_size)
28124
Old page size (old_size)
27042
Size change in edit (edit_delta)
1082
Lines added in edit (added_lines)
[ 0 => '*[[Rust (programming language)|Rust]]', 1 => '*[[<ref>Traits in Rust</ref>https://doc.rust-lang.org/book/ch10-02-traits.html (programming language)|Rust]]', 2 => '</syntaxhighlight>', 3 => '', 4 => '=== In Rust ===', 5 => 'Rust makes extensive use of mixins via ''traits''. Traits, like in Scala, allow user to implement certain behaviour for a defined type. They are also used for [[Generic programming|generics]] and [[dynamic dispatch]], which allow for types with same traits to be used interchangeably statically or dynamically at runtime respectively.', 6 => '', 7 => '<syntaxhighlight lang="rust">', 8 => '// Allows for types to "speak"', 9 => 'trait Speak {', 10 => ' fn speak();', 11 => '', 12 => ' // Rust allows implementors<ref><ref><ref><ref><ref><ref><ref><ref><ref></ref></ref></ref></ref></ref></ref></ref></ref></ref> to define default implementations for functions defined in traits', 13 => ' fn great() {', 14 => ' println!("Hi!")', 15 => ' }', 16 => '}', 17 => '', 18 => 'struct Robot;', 19 => '', 20 => 'impl Speak for Robot {', 21 => ' fn speak() {', 22 => ' println!("Beep beep boop boop");', 23 => ' }', 24 => '}', 25 => '', 26 => 'struct Dog;', 27 => '', 28 => 'impl Speak for Dog {', 29 => ' fn speak() {', 30 => ' println!("Woof woof");', 31 => ' }', 32 => '', 33 => ' // Here we override the definition of Speak::great on Dog', 34 => ' fn great() {', 35 => ' println!("Robot says howdy!")', 36 => ' }', 37 => '}' ]
Lines removed in edit (removed_lines)
[ 0 => '*[[Rust (programming language)|Rust]]' ]
Whether or not the change was made through a Tor exit node (tor_exit_node)
false
Unix timestamp of change (timestamp)
1650464588