Announcing Mixen: Multiple Inheritance in JavaScript | Hacker News Reader

Announcing Mixen: Multiple Inheritance in JavaScript

dev.hubspot.com

17 pointszackbloom14 comments

Misleading title; Coffeescript != JS. And while it's certainly possible to use this in JS, it's not particularly clean.

I don't think that's misleading at all. CoffeeScript generates JavaScript. It's literally the only thing it does.

When you use this library, you're including a JavaScript file in your page (or requiring it in your Node project). It just so happens that in this case, the author(s) happened to use CoffeeScript to help them write that JavaScript.

Coffee script may compile (or transpile, depending on your preferred term) into javascript...but it isn't javascript.

Misleading title...

C exists only to be compiled. Should math.h be considered an x86 assembly library?

I'm writing an article titled "Performance of the & selector in CSS". I'd love you to defend it in the HN thread when it's done.

It's unfortunate, but JS is just never going to be as clean as CoffeeScript.

The JS CoffeeScript produces is never going to be as clean as well-written JS. Since you cannot avoid the JS but you can avoid CS, I choose the former.

There's also traits.js, which in my view is too little known in the pro JS dev community:

http://soft.vub.ac.be/~tvcutsem/traitsjs/

https://github.com/Gozala/light-traits/

Also (but far less known) riveter.js: https://github.com/a2labs/riveter

Even though OP is about Coffeescript (which != JS), I think my comment is still relevant.

This is from an older SO post I made[0]: (The context is immediately invoked function expressions) IIFEs are often confusing to read and personally, I have no idea why they have become so mainstream. I think code should be easy to read and concise. Attempting to simulate language behavior that is not part of the language specification is often-times a very dumb idea.

For example, JavaScript does not support multiple inheritance, polymorphism, or many other interesting paradigms. So a lot of times, we see people trying to create these crazy ways of sorta'-kinda' having polymorphism or private members, etc in JS. I think this is a mistake.

[0]: http://stackoverflow.com/questions/12078812/how-to-choose-oo...

I completely agree, except for the private methods portion. I personally find

    (function(){
        //implementation methods and variables
        return{
            //public methods
        };
    })()

to be far easier to read than

    var myObject = {
        //A random mix of public and implementation details
    };

Though I will admit that my main reason for believing the above, is that when you work with developers who do not spent much time in JS, and they realize they have to write something complicated without private methods, they tend to write either monstrously long public methods as a result, or write as normal and litter the interface of the object, thereby completely breaking SOLID. The first method above avoids that problem.

Usually I would be against simulating language features which aren't part of the language in the first place. JavaScript is kind of different, though.

On the web, many developers are "forced" to write JavaScript when they don't really understand it (which is a massive pet peeve of mine, but that's a rant for another time). These developers tend to try and shoehorn design patterns from their language of choice into JS, or they just don't use any design patterns at all. Either way, it just doesn't work; the code just ends up being horrible.

At least libraries like this allow people to use design patterns that are more familiar to them, which should (hopefully) result in cleaner code.

When I was starting out with JavaScript I had a little mantra that was "It's dynamic, stupid!" Which was almost always the answer to any point of confusion. Once I got around to seeing that object prototypes were just a tiny bit of magic glue, not only did the nature of constructor Functions make sense, but the inheritance mechanism became obvious. At that point JavaScript really transcends notions such as Multiple Inheritance because "It's dynamic, stupid!". Not only can you get the effects of Multiple Inheritance, but you can shift the object relationships around willy nilly. It's all just JavaScript. You are not so much adding a feature as creating an API to restrict your use of the natural ability in order to preserve your sanity.

Why would anyone want multiple inheritance?

Composition > class hierarchies

Reply on news.ycombinator.com