Suggestion: optional interface

[vvakame]

I think this is useful syntax :)

sample.

interface IFoo {
  foo: string; // not optional
}

class Bar implements IFoo? {
  // Bar does not have a foo property.
}

new Bar().foo;

How useful.

class Foo implements Lib.IListener? {
  constructor() { Lib.injectInto(this); }
}

module Lib {
  export interface IListener {
    on(data: any): void;
  }

  export function injectInto(target: any) {
    target.on = () => { /* do something... */ }; 
  }

  export function listen(receiver: IListener) {
    receiver.on("foobar");
  }
}

var obj = new Foo();
Lib.listen(obj);

Lib.listen({
  on: ()=> {} // on method required
});

In real world.

case 1.
https://github.com/borisyankov/DefinitelyTyped/blob/705102df2b652bdbadad23561675116a26e48760/space-pen/space-pen.d.ts#L52

case 2.
// Emissary#emitter
https://github.com/atom/emissary#emitter
// .d.ts
https://github.com/borisyankov/DefinitelyTyped/blob/b4aba562ef4192bc3f2e770ab2018f89e047836b/emissary/emissary.d.ts#L13
// usage in TypeScript (dirty hack!)
https://github.com/vvakame/language-review/blob/d23f8797bbb6e99d636399a14c7035c4809ab365/lib/util/emissary-helper.ts#L11

[basarat]

This is an alternative syntax suggestion for #340

But still 👍

[basarat]

Admittedly this way we do not break existing code.

[basarat]

Another use case is making mixins easier

[RyanCavanaugh]

Major question I have here is that an important use case for mix-ins is that you would be able to add one of these optional interfaces after the fact, which doesn't work well with having to declare this on the original class declaration. A solution for this JS pattern should be able to handle both cases.

[vvakame]

Sorry English is not my first language.
Do you say How to mix-in interface to already defined class??

I think we should expand TypeReference grammer.
TypeName [no LineTerminator here] TypeArgumentsopt to TypeName [no LineTerminator here] TypeArgumentsopt ImplementsClauseopt.

use case.

module Lib {
  export interface IListener {
    on(data: any): void;
  }

  export function injectInto<T>(target: T): T implements IListener {
    var modified = <T implements IListener?> target;
    modified.on = () => { /* do something... */ }; 
    return modified; // IListener? has compatiblity to IListener. I think this is programmer's duty.
  }

  export function listen(receiver: IListener) {
    receiver.on("foobar");
  }
}

var receiver = Lib.injectInto({ name: "vvakame" });
// typeof receiver === ({name: string;} implements IListener)
// I want to get expanded object type literal like {name: string; on(data: any): void;} on error message.
receiver.on("foobar");
receiver.name;
Lib.listen(receiver);

[s-panferov]

+1 to something that can fix the current TypeScript mixins issues. Things like ReactJS using mixins widely and now it is very hard to make TypeScript compiler check all this things property without some effort.

For example, there are more than 400 components in my project and it will be a little bit crazy to repeat React's method defs inside every component. On the other hand i want to type-check my code. So i find out to define classes like this:

class LinkComponent extends ReactComponentBase<LinkComponentOptions,{}> implements React.ReactComponentSpec<LinkComponentOptions,{}> {
   // extends Component<LinkComponentOptions,{}> for instance methods like setState
   // implements React.ReactComponentSpec<LinkComponentOptions,{}> for type check livetime methods
}

 // this is an `empty` class to satisfy the compiler
 export class ReactComponentBase<P, S> implements React.ReactComponent<P, S> {
    state: S;
    props: P;
    refs: { [ref: string]: React.ReactComponent<any, any>; };
    getDOMNode: () => Element;
    setProps: (nextProps: P, callback?: () => void) => void;
    replaceProps: (nextProps: P, callback?: () => void) => void;
    transferPropsTo: <C extends React.ReactComponent<P, any>>(target: C) => C;
    setState: (nextState: S, callback?: () => void) => void;
    replaceState: (nextState: S, callback?: () => void) => void;
    forceUpdate: (callback?: () => void) => void;
  }

This leads to emty class ReactComponentBase that includes to every component (in compiled js code) and looks very ugly. And for my project's react mixins i need to create additional (empty) classes that extends ReactComponentBase and provide correct mixin's methods.

export class MixinsComponent<P, S> extends ReactComponentBase<P, S> {
    // example of mixin method
    onValue: (bus: Bacon.Bus<any>, foo: (val: any) => void) => void;
}

I think that implementation of normal mixins and unit types will make TypeScript much more friendly to such kind of libs.

[sedwards2009]

Dojo is another example of a big library which could benefit greatly from TypeScript but also makes extensive use of mixins. It is not uncommon for classes in an application to require the use of 3 extra mixins. Using Dojo with TypeScript isn't really practical at the moment.

[nycdotnet]

Just chiming in that this would be really useful. I had requested something like this on CodePlex last September.

https://typescript.codeplex.com/workitem/1631

[basarat]

There is also : https://typescript.codeplex.com/workitem/1885 and https://typescript.codeplex.com/workitem/2475