Hacker News new | past | comments | ask | show | jobs | submit login
JavaScript Mixins for grown-ups (javascriptweblog.wordpress.com)
51 points by northstar on June 4, 2011 | hide | past | favorite | 7 comments



Note that the way mixins generally work in languages with first class support for them is with multiple inheritance. That is, mixins are included by reference and, in a dynamic language, changes to the mixin affect objects that have already been extended.

JavaScript can't do multiple inheritance and so you have to hack mixins by copying. This sucks when you want to e.g. extend an Enumerable mixin because.. well, you can't.


> JavaScript can't do multiple inheritance

JS's object modell is prototype based, so there's no traditional inheritance, just the chain of prototypes. And you can monkey patch it any way you like at any level. (Adding currying to Function.prototype is a nice and scary example of this.)

Directly defining functions into the prototype chain doesn't even require copying and you can put an arbitrary number of functions there. And you can just redefine the Enumerable mixin's functions, or wrap then into your functions, so extending isn't a problem.


By "multiple inheritance", I mean children can inherit features from multiple parents, whatever the constraints on those parents may be. Ruby, for example, uses modules for this purpose.

Because JS objects can only have a single prototype, you can't inherit from multiple places orthogonally. If you insert mixins into the prototype chain then they can't be shared between multiple chains, and so aren't really mixins.


Uh, can you elaborate more? Mixins work just fine in Ruby which has no multiple inheritance.

You don't have to "hack mixins by copying" in Javascript. And what did you mean by the last sentence?


I think they mean that you can't set multiple prototypes, and there's no way to capture calls to "obj.something_undefined" values or methods, so you have to copy the interfaces of anything you wish to mix in. Which means breaking prototypical inheritance with your mixins - they can't change, because anything set up by such copying won't get updated.

Specific quote my reasoning is based on: ... changes to the mixin affect objects that have already been extended.

edit: well... you could. By making mixin objects that propagate changes to themselves to instances of things which include them - pass each instance to the mixin, and keep a list. But that'd end up making your entire program into one big memory leak, unless you want to go down the constructor/destructor and manual memory management route in JS. I doubt it's worth it.


http://wiki.ecmascript.org/doku.php?id=harmony:proxies

Proxies, which are only supported currently in Firefox but should see support in other browsers eventually, will allow you to intercept all types of property access/manipulation on objects. This will allow generalized multiple inheritance and dynamic mixins; I wrote basically that using node-proxy for Node.js.


This post inspired me to try and create the mixin pattern in C# with interfaces, extension methods, and optional generics. Probably been done before, but meh, here's the result: http://pastebin.com/ZiddNDSi




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: