Exploring Mixins And Javascript Objects
After my in-depth exploration of ColdFusion mixin behavior, Rick Osborne asked me how this would compare to mixin behavior in Javascript. I think Rick just likes making my head hurt, but it was an interesting question so I thought I would explore it. It's actually especially interesting because Javascript has both object binding and lexical binding. By that, I mean that Javascript functions can be used in objects, but they also have access to the parent scope in which they were defined (see my graphical explanation of closures). Seeing how this works in the context of method mixins would certainly be interesting.
The code for this test is actually quite short, so I'll show it first then explain it:
<script type="text/javascript">
// Run the following code in its own private bubble.
(function(){
var strDate = "Thursday, 4/2";
// Define method outside of object.
window.PublicFunction = function(){
document.write( strDate + "<br />" );
document.write( "I am a public function<br />" );
}
// Define method outside of object.
window.PublicFunctionWithThis = function (){
document.write( strDate + "<br />" );
document.write( this.Name + "<br />" );
}
})();
// ------------------------------------------------- //
// ------------------------------------------------- //
// Define our test object.
function Mixin( strName ){
this.Name = strName;
}
// Create an instance of our object.
var objMixin = new Mixin( "Molly" );
// Bind the simple alert function and execute.
objMixin.PublicFunction = PublicFunction;
objMixin.PublicFunction();
// Bind the THIS-reference alert function and execute.
objMixin.PublicFunction = PublicFunctionWithThis;
objMixin.PublicFunction();
</script>
In the first part of the code, I define a function and then immediately execute it within it's own private bubble (function context). By doing this, I ensure that the variable "strDate" is not available to the global scope (window). Then, I define my two methods. They both reference the strDate variable; as seen in my closure demonstration, they will both have access to this variable (lexical binding). The second one, however, alerts "this.Name", a variable which is, at this time, undefined.
Then, I create an object with a "Name" property (remember the this.Name from above). Then, I mixin these two methods and execute them. This is the output we get:
Thursday, 4/2
I am a public functionThursday, 4/2
Molly
This is very cool! The methods use both runtime and "compile" time binding. The first method really isn't that interesting; but, the second method, PublicFunctionWithThis(), is fascinating. On one hand, it is able to reference the "strDate" variable from its compile-time context, and on the other hand, it is able to access this.Name from its run time, object binding. It get's the best of both worlds!
Want to use code from this post? Check out the license.
Reader Comments
Very nice Ben, this will definitely come in handy!
I liked that you explicitly bound the variables to the global "window" object. The best practice is to explicitly define local variables with 'var' and global variables as 'window.foo'.
You could theoretically leave off the 'var' to implicitly set a global variable. But this entails a performance hit, as the JS interpreter has to search the entire scope chain for the variable. It also leaves you open to exciting bugs if a later code change defines a 'foo' variable somewhere in the scope chain between your function and the global scope.
The main drawback of this approach is that the code is less easily reusable outside the context of a browser. In other JS environments (such as Mozilla Rhino) there is no global window object. This drawback is easily ignored for most developers, but it's useful to know.
@David,
I actually picked that up looking through the jQuery library code :)
I guess you could get around the window scope issue in Rhino by passing in the global scope:
(function( window ){ .... })( window );
... like how they pass jQuery in and bind it to the $. Unless "window" is an illegal variable name.
As always, very well and concisely done, sir.
@Rick,
Thanks you good sir.