Should `interface` reject static interface members?

[popham]

I just tried to use a static member function within an interface, and I got an unexpected identifier error:

/* @flow */

interface A {
  static someStatic(): void;
} // inter.js:4:10,10: Unexpected identifier

Is relaxing Type._object env to Type._object ~allow_static:true env (src/parser/parser_flow.ml) fraught with peril? (I expect the override semantics of class to get applied, so I don't see any problem.)

[gabelevi]

How would you like to use an interface with static members? Can you give a small motivating example?

[popham]

The case that won't go away is alternate constructors:

interface I {
  static ctorPattern1<T>(p1: number): T;
  static ctorPattern2<T>(p1: string): T;
}

I don't think that interfaces can add anything to Flow without statics. Simple types combine with the intersection operator to provide without-statics interfaces:

interface J {
  sMethod(): void;
  method(): void;
}

interface K {
  method2(): void;
}

class C implements J,K {...}

versus

type J = {
  sMethod(): void;
  method(): void;
};

type K = {
  method2(): void;
};

const C: J & K = class {...};

[popham]

Looks like a recent commit picked this up. Whoo hoo.

[popham]

The parse errors went away. Unfortunately, Flow doesn't check the types.

[calebmer]

TypeScript doesn’t support this behavior, and I personally don’t think we should either. Please let me know if you disagree 😊

[popham]

I disagree. Statics are available on JS instances through constructor. Shouldn't Flow reasonably handle the following?

interface I {
  constructor: {
    a: string
  }
}

Isn't static sugar preferable?

[calebmer]

Interfaces don’t really represent instances in the same way classes do. It’s better to think of interfaces as a classlike sugar for defining object types like type I = {} 😊

However, I see your usecase and we’d love to support a pattern like:

type InstanceStatic = {
  staticA: number,
  staticB: number,
  staticC: number,
  new (): Instance,
};

type Instance = {
  a: number,
  b: number,
  c: number,
  constructor: InstanceStatic,
};

If you don’t want to use ES6 classes 😊

[popham]

Hmm. Given object type kinda-inheritance via the spread operator, if implements is extended to operate with object types, I'll never touch interface again. Is it fair to say that interfaces are intended mostly to track TypeScript's for cross-compatibility?