Explain why private and protected members in a class affect their compatibility

TypeScript Version: up to 2.5.2 at least

In the doc a short paragraph explains that private and protected members in a class affect their compatibility.

I have been searching for a while in the design goals, on SO etc… but could not find a decent explanation of the rationale. Could we:

• either document the rationale (in the paragraph above?
• or consider evolving the language?

Note: I found one rationale close to what I am looking for, but you could imagine that the language “reserves” the private names but does not compel to use them.

Code This behavior is especially an issue in unit testing where you want to mock a class, disregarding its internals…

class MyClass {
    pubfield = 0;
    private privfield1 = 0;
    constructor(private privfield2: number) {}
    private method(): void {}
}

class MyClassMock implements MyClass {
    pubfield: number;
    // *** compile errors on missing properties ***
}

Expected behavior: I would like to only care about the public contract that a class-under-test can possibly use from my mock.

Actual behavior: I cannot limit my mock to the public fields.

The ugly workaround I found is the following:

class MyClass {
    pubfield = 0;
    private privfield1? = 0;
    private privfield2? = 0;
    // do not use the shortcut notation because the constructor param is not optional!
    constructor(privfield2: number) {
        this.privfield2 = privfield2;
    }
    private method?(): void {}
}

class MyClassMock implements MyClass {
    pubfield: number;
}

What I do not like is that I have to modify the semantics of my class to be able to mock it and that I am scared that a future overzealous refactoring may use the shortcut notation for fields declaration in the constructor… making the constructor param optional (!)

[tao-cumplido]

@renatomariscal @jandsu You can create such a type easily yourself with keyof, it only picks the public members.

type Public<T> = { [P in keyof T]: T[P] }

[RyanCavanaugh]

Allowing the private fields to be missing would be an enormous problem, not some trivial soundness issue.

Consider this code:

class Identity {
  private id: string = "secret agent";
  public sameAs(other: Identity) {
    return this.id.toLowerCase() === other.id.toLowerCase();
  }
}

class MockIdentity implements Identity {
  public sameAs(other: Identity) { return false; }
}

MockIdentity is a public-compatible version of Identity but attempting to use it as one will crash in sameAs when a non-mocked copy interacts with a mocked copy.