Support extending a mixin application expression directly

[rictic]

@azakus has talked to some folks about this offline but I wanted to make an issue to link to / track.

Currently to support ES6 class mixin, one must do something like:

// declaration


/**
* @interface
*/
function TimedInterface(){}
/** @type {number} */
TimedInterface.prototype.time;

/**
 * @template T
 * @param {T} mixin ES6 class expression mixin to wrap
 */
function Timed(superclass) {
  return class extends superclass {
    constructor {
      /** @type {number} */
      this.time = 0;
    }
  }
};

// use

/**
 * @implements {TimedInterface}
 * @extends {Foo}
 */
const TimedFoo = Timed(Foo);

class Bar extends TimedFoo {};

There are two suboptimal parts to this. The first is that we need to manually duplicate the interface of the Timed class in TimedInterface. The second is that we can't write class Bar extends Timed(Foo) {} because extending an expression isn't supported.

[ChadKillingsworth]

There's already an issue for extending an expression, and that one is a pretty high priority fix for me.

The other affects the type system and is more involved.

[rictic]

There's #2106 but if I'm reading that right, it was closed once closure compiler allowed unknown types in the @extends annotation, rather than in allowing expressions in the ES6 extends clause. Maybe worth reopening to track allowing the syntax, and this issue can be for inferring the interface type of a mixin?

[ChadKillingsworth]

I may have been thinking of #2182. It's possible that one is fixed though.

I've definitely looked into this. The expression decomposer won't handle that case. Haven't had a chance to figure out why.

[simonfuhrmann]

Is there an update or a timeline when this gets supported?
Currently, dealing with mixins in Polymer-based applications is a little awkward. The JS Compiler error I am getting for mixin expressions is: ERROR - The class in an extends clause must be a qualified name.

[ChadKillingsworth]

@shicks We talked about this last week. Any thoughts on how this might work?

I see two major cases:

1. The source of the mixin function is visible to the compiler and type inference can assist.
2. The source of the mixin function is hidden to the compiler (like an extern). We probably have to fall back to the manual interface for this case?