Mixins and the applyMixins function?

[blendsdk]

Hi,

Since the compiler can distinguish between a class being used as an interface, what is the reason the compiler does not automatically emit "applyMixins" at the end of the compilation cycle? It there a particular reason for this?

Regards,
Gevik.

[danquirk]

Are you asking why the current behavior is this?

class Foo { 
   doStuff() { return 'hi'; }
}
class Bar implements Foo { // error here, but should automatically mixin doStuff?
}

[benliddicott]

I think the question is, why can't we do this:

class Foo { 
   doStuff() { return 'hi'; }
}
 class Yung { 
   doStuff2() { return 'hi'; }
}
// FAILS
class Bar extends Foo, Yung { // error here, but should automatically mixin doStuff?
}

Currently we do:

// SUCCEEDS

class Bar extends Foo implements Yung {
constructor(){super();}
}
applyMixins(Bar, [Yung]);

I think @blendsdk is asking why you can't extend two classes, and the compiler emit the applyMixins call automatically, to implicitly turn the FAILS example into the SUCCEEDS example.

[danquirk]

Because the type system is structural the extends and implements clauses are generally best thought of as statements of intent and a desire to have the compiler validate you have done what you intended.

At this point changing the behavior of these statements would be an enormous breaking change so it's not something we'd do without new syntax of some sort.

[benliddicott]

@danquirk thanks for the note. I get changing the behaviour of implements would be a breaking change. But allowing multiple extends with different semantics for the second onwards, would not, since these are currently syntax errors. (Actually I am not advocating this, I am advocating #3854 as a different route to the same goal. I just picked this issue up while looking for related issues. I am just trying to clarify what I take to be the OP's point.)