Problem You want to implement Ruby-style mixins in JavaScript to easily extend object functionality. Theory In Ruby, mixins are a way of extending the functionality of an object by adopting the functionality of another object. When you instantiate a JavaScript type, the methods and properties associated with the type depend on the declaration of the type. To extend the functionality of an instance, a property is assigned with a function or another object.

   Source: /website/ROOT/ajax articles/javascript/mixins.html
   function DefinedClass() {
   }
   DefinedClass.prototype.defined1 = function() {  }
   DefinedClass.prototype.defined2 = function() {  }

The DefinedClass function is used to define a type. Two methods, defined1 and defined2, are associated with the DefinedClass type. Each method is associated with the prototype property, so every time DefinedClass is instantiated, these methods will share the same function instance. Thus, if you assign a property of defined1 or defined2, then all instances of DefinedClass will be able to share the same property instance. Solution To extend an instance of DefinedClass, you could individually assign the properties of the instance. Individually copying a property is tedious; a more efficient solution is to copy the properties of one object to another object. Many frameworks, such as Prototype and Dojo Toolkit, provide the ability to copy properties. Following is the mixin implementation for Prototype.

   Source: /website/ROOT/prototype/dist/prototype.js
   Object.extend = function(destination, source) {
   for (property in source) {
   destination[property] = source[property];
   }
   return destination;

The Object.extend function has two parameters: destination and source. The destination parameter represents an object that will have properties added. The source parameter represents an object that will have its properties copied. The properties are copied using a for loop because it is not possible to iterate the properties of an object instance in any other way. The property identifier, not the property value, is iterated. To retrieve the property value, you could use the following syntax: source.property The problem with this notation is that the property is defined explicitly, and using it in the context of implementing a mixin function is complicated. The solution is to use the JavaScript array notation and retrieve the property as an array. Going back to the Prototype solution, as each property of the source is iterated, the value is retrieved and assigned to the destination. Let’s apply the extend method using the following object instance declaration.

   Source: /website/ROOT/ajax articles/javascript/mixins.html
   MyExtensions = {
   test : function(tstValue) {
   assertEquals(tstValue,  MyExtensions.test.value);
   }
   }

The MyExtensions class declaration is a static reference to a single embedded property that is an instance of type Object. We want to copy the property to an instance of DefinedClass, as shown in the following test.

   Source: /website/ROOT/ajax articles/javascript/mixins.html
   prototype_mixin : function() {
   var cls = new DefinedClass();
   if( MyExtensions.test.value) {
   testManager.failed();
   }
   Object.extend(cls, MyExtensions);
   cls.test.value = 3;
   cls.test(3);
   cls.test.value = 10;
   cls.test(10);
   },

The test code goes beyond the simple calling of Object.extend, but reveals that most toolkits implement mixins using duck types based on references. It is not wrong, but because functions are objects they will be shared among multiple class types. To understand this, look at the implementation of MyExtensions.test. The implementation references the test.value function property and cross-references it with the tstValue parameter. In the implementation of the prototype_mixin function, an instance of DefinedClass is created and then extended with the methods of MyExtensions. The cls.test.value property is assigned a value of 3, and the test method is called.

The implementation of test verifies the value of MyExtensions.test.value as 3. If the test method of cls were a copy of the MyExtension.test method, then the test would fail because MyExtensions.test.value has not been assigned, as evidenced by the if test block. But the test code does not fail, which indicates that cls.test and MyExtensions.test are one and the same method. Referenced-based duck typing has some odd behaviors, one of which is shown in the following code.

   Source: /website/ROOT/ajax articles/javascript/mixins.html
   function GetExtensionFunctionality() {
   return {
   test : function(tstValue) {
   assertEquals(tstValue, this.test.value);
   }
   }
   }
   prototype_inconsistent_mixin : function() {
   var cls1 = new DefinedClass();
   var cls2 = new DefinedClass();
   Object.extend( cls1, GetExtensionFunctionality());
   Object.extend( cls2,  GetExtensionFunctionality());
   cls1.test.value = 3;
   try {
   cls2.test( 3);
   }
   catch( e) {
   if (e.jsUnitMessage) {
   info("prototype_inconsistent_mixin",  "Expected exception
   (" + e.jsUnitMessage + ")");
   }
   }
   },

Here, the extended functionality is defined in the context of a method call. In the previous example, the test method was shared by multiple classes. In the test, cls1 and cls2 should also share the same test method. Running the test code will result in an expected exception stating that cls.test.value does not have the value 3. In a nutshell, the problem is that you have two ways of calling Object.extend, and you get two completely different behaviors due to the nature of value- and reference-based duck typing. It is something that you need to be aware of, because you might get some odd behavior. Of course, a counterargument could be that if you think about the nature of the prototype property, the same sort of behavior results. I agree that is the case but also realize that the examples did not use the prototype identifier. A JavaScript developer knows what the ramifications of prototype are, and thus will know when to use and when not to use the keyword. In this article’s examples, a prototype behavior was illustrated without using prototype. We know about this situation and have two mixin methods: one that copies references (reference duck typing) and one that does a complete copy (value duck typing). The complete value-based duck-typed mixin implementation follows.

   Source: /website/ROOT/scripts/jaxson/common.js
   mixin : function( copyTo, copyFrom, forceCopy)  {
   var  copiedFrom = eval( ops.singleSerialize( copyFrom));
   for (property in copyFrom) {
   if((copyTo[ property] && force) ||  !copyTo[ property]) {
   copyTo[ property] = copiedFrom[ property];
   }
   }
   }

In the implementation of the mixin method, the first step is to generate a buffer of the instance to be copied (ops.singleSerialize), and then execute the buffer using eval. The process of generating a buffer and then executing it has the effect of cloning the object and its properties. Then when the clone is iterated, the object to be extended has references to the cloned object, and not the original object. This fulfills the requirement that the object to be extended has copied the properties of the source object.

In the article’s source code, you’ll also find a method called ops.refMixin, which behaves like the other mixin implementations and assigns references to the object to be extended. When implementing mixins, keep the following points in mind:

• Mixins are a way of extending the functionality of an object by adopting the functionality of another object. In JavaScript, you can replicate this technique by copying the references or by copying the functionality directly.

• Mixins are a form of prototype-based programming where the behavior of the object is determined at runtime.

• You may not write properties that are part of functions, and thus think that the reference copying is not a problem. But be forewarned: if your source object references properties that reference objects, then the object is not copied, but rather the reference to the object.

• You will use mixins extensively when writing JavaScript code, so be careful with your objects and references.