Multiple inheritance? Mixins?

[TrevorBurnham]

I'm loving the extends keyword, but in the course of developing a complex project, I really wish I could give a class functionality from multiple sources. Obviously I could do this by extending the prototype manually, but it feels like a hack to mix the extends syntax with JavaScript-style prototype manipulation.

For my purposes, it would be great to be able to say

class A extends Foo, Bar

but I realize that multiple inheritance is a huge headache, so Ruby-style mixins or Scala-style traits would probably be a better solution. The Scala syntax would be especially nice for CoffeeScript:

class A extends Foo with Bar

Obviously with is already a keyword, but its meaning in this syntax is unambiguous.

Of course, this is something that a standard library could do, but it would be much clearer to have something like the above syntax rather than something like

class A extends foo
   # properties...

lib.mixin A, bar

What does everyone else think?

Yes, mixins - I'm missing them too.

[jashkenas]

So. JavaScript inheritance of properties through prototypes is only for single inheritance. You can have chains pointing back as long as you like, but there's only one prototype per-object.

Any "mixin" functionality would be limited to what can be accomplished at runtime through helper functions, as mentioned above. It would be a blind copy of properties onto the object or prototype, not a true inclusion, where subsequent changes to the module would affect the mixed-in objects. For this reason, I don't think that it's in the domain of CoffeeScript. Is there a concrete proposal for what you'd like it to compile into?

[TrevorBurnham]

I would like

class A extends Foo with Bar, Baz

to copy the properties from the Bar and Baz prototypes over to A. Naturally, I wouldn't be able to use super if I overrode a Bar or Baz function, because that could be ambiguous. It would still be quite useful, though, for adding certain kinds of functionality to multiple classes. It's syntactic sugar, plus folks coming from Ruby probably expect some kind of mixin functionality in the language.

[tcr]

class A extends Foo merge Bar, Baz

?

[jashkenas]

Closing this one as a wontfix, here's why:

The idea with CoffeeScript classes is to expose the common pattern of use of JavaScript's prototype chains in a convenient way -- not to mimic classes from Ruby or another language. If you'd like to include methods from an external module into a class you have a number of options: you can delegate to the class, manually copy methods over, or use a helper function like Prototype's extend.

It's an orthogonal issue to classes ... you should equally well be able to "mixin" functions into a vanilla object, which is something that an extend function does.

[StanAngeloff]

Mootools solves this using an Implements property. A Class in Mootools can extend only one other, but can implement as many as required. A common example is:

Button: new Class {
  Extends: Control,
  Implements: [Options, Events]
}
cancel: new Button()
cancel.addEvent 'click', ( -> false)

This is very powerful and I use it quite a lot in my code. Options and Events are so common that every UI class must have them.

I personally think Coffee should have a second think about allowing this kind of construct.

class Button extends Control implements Options, Events

From the docs:

Extends

The Class that this class will extend. i.e. proper inheritance

Implements

Implements is similar to Extends, except that it adopts properties from one or more other classes without inheritance. Useful when implementing a default set of properties in multiple Classes.

[jashkenas]

We can reopen it if someone cooks up a patch they'd like to propose.

[hen-x]

If we had inline anonymous classes, it would be possible to implement mixins in user code while keeping them at the top of the class definition:

implementing: (mixins..., classReference) ->
    for mixin in mixins
        for key, value of mixin::
            (classReference::)[key]: value
    classReference

Button: implementing Options, Events, class 
    doSomething: ->

cancel: new Button()
cancel.addEvent 'click', ( -> false)

...although a class defined this way could not have a subclass containing super calls, since it would not be bound to a name at compile-time.

[koops]

+1 for some kind of mixin functionality. It seems awkward and un-coffee to create a class and then copy functions to the prototype after the definition. That functionality feels like it belongs in the class definition.

[dfreire]

+1

[Goutte]

class Options
  options: {}
  setOptions: (o) ->
    for own key, value of o
      @options[key] = value
    this

class Button extends Control implements Options, Events

+1

[omo]

+1

[jashkenas]

Sorry, folks, but +1s aren't terribly helpful without a specific implementation strategy you'd like to propose. Multiple inheritance simply does not exist in JavaScript -- you have a single __proto__ property, which points at a single parent object.

[omo]

@jashkenas Thanks you for you response and I'm sorry for my noisy comment...
Simple function copying like Backbone.Events is a good starting point for me.
For name conflicts, I prefer just throwing error to avoid accidental override.

[ricardobeat]

You can have a longer prototype chain, or am I doing something stupid?

x = function(){};
x.prototype = { x: 1 };
y = function(){};
y.prototype = new x();
y.prototype.y = 2;
z = function(){ this.z = 3; };
z.prototype = new y();
z.prototype.z = 3;
a = function(){};
a.prototype = new z();
a.prototype.a = 4;

console.log(new a)

x.prototype.b = 5;

console.log(new a);