Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
branch: master

found German draft from October 21, 2009 - shared it on Google Drive/…

…Docs - did add this link to this resources list.
latest commit 61115bc6d9
@petsel authored
..
Failed to load latest commit information.
Mixins setting up this new project mainly for documentation reasons in order…
Traits setting up this new project mainly for documentation reasons in order…
README.md

README.md

(kind of historical documentation)

Every now and again it happened and still does that JavaScript programming individuals each on their own discover this languages capability for - what then mostly gets referred to as - "functional or function based mixins". Most of them understand in this very moment the impact of theirs discovery in means of working with a different design approach for theirs future project architectures and code bases (modularisation, code recycling, creating types, generating type/object systems). But how does it come?

JavaScript is a delegation language. This languages core features are all about Object and Function and closures as much as about call and apply ... and yes about prototype too. Do value the last mentioned but don't adore it blindly. Delegation in JavaScript already happens implicitly when the prototype chain is walked in order to e.g. find a method that might be related to but is not directly owned by an object. Once the method was found it gets called within this objects context. Thus inheritance in JavaScript is covered by a delegation automatism that is bound to the prototype slot of constructor functions.

But almost from its beginning JavaScript has been capable of delegating a function or a method directly to an object that has need of it via call or apply - example:

var cat = {
  sound     : "meow",
  makeSound : function () {
    console.log(this.sound);
  }
};
var dog = {
  sound     : "woof"
};

cat.makeSound();          // "meow"
cat.makeSound.call(dog);  // "woof"

But instead of wildly "borrowing" such methods again and again the next step towards code improvement should be collecting them and providing them, when needed.

var Talkative = function () {
  makeSound: function () {
    console.log(this.sound);
  }
};
var cat = {
  sound: "meow",
};
var dog = {
 sound: "woof"
};
Talkative.call(cat);
Talkative.apply(dog);

cat.makeSound(); // "meow"
dog.makeSound(); // "woof"

Talkative is a reusable module of code. Ruby supports including such modules and calls them Mixins. Perl 6 has its own approach called Roles.

As has been pointed out already in the resources listed right at the bottom ...

Peter Seliger Sun, 14 Apr 2013

... this languages capability for "functional or function based mixins" might deserve a closer look before running into what I would call a meta programming temptation trap.

We already have everything we need in order to create modular collections of behavior and also in order to provide and apply them to objects.

"Mixin" might be a Ruby influenced term and does not completely cover what can be achieved by functions/closures [call] and [apply]. I'd rather tend to use Perl 6 "Roles" as a generic term.

The smallest thinkable Role was a function body that implements a single method in a stateless way. Thus being a "Trait" if one follows the findings of the "Software Composition Group" at Bern University [http://scg.unibe.ch/research/traits]. Any implementation that gets injected mutable state or does create mutable state on its own in oder to solve its task(s) then, from my point of view, should be referred to as "Mixin".

Andrea Giammarchi Sun, 14 Apr 2013

It seems that Mixins Are Awesome and this can take most advantages from being a function and not only an object: http://webreflection.blogspot.ie/2013/04/flight-mixins-are-awesome.html

AFAIK, all interfaces described in W3C such EventTarget and others could be also covered by this proposal ... so ... what do you think ?

Peter Seliger Sun, 14 Apr 2013

... , you are right, but all it needs in my opinion are a module pattern, a module library of your choice, a naming convention for your Trait/Mixin-module Implementation (adjectives/adverbes, no nouns, first uppercase letter?) and again [call] or [apply].

For your given example of W3C interfaces, [EventTarget] should be implemented and internally referred to as [EventTargetMixin], but the module should expose [EventTargetMixin] as [Observable].

There is another point that makes pure straightforward functional Trait/Mixin composition unique in JavaScript - passing additional data at apply time. ... ...

With meta programming approaches this advantage, one gets for free now, might get lost or if implemented less understandable.

I discarded every single approach I made within the last 5 years for Trait/Mixin libraries, that tried to be smarter than what the languages core already provides except the last one that just sticks to a module library. ...

Resources (increasingly sorted by date):

German only:

English:

Something went wrong with that request. Please try again.