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

[jandsu]

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 (!)

[kitsonk]

Because, at the moment, in ECMAScript, there is no real private or protected, therefore they affect the shape of the object, and therefore it is safer to consider them for assignability purposes. This keeps you from accidentally overwriting private or protected members.

Consider the following:

class Foo {
  private _bar = 'bar';

  log() {
    console.log(this._bar);
  }
}

class Baz extends Foo {
  private _bar = 'baz';
}

const baz = new Baz();
baz.log(); // if TypeScript allowed it, it would log "baz" which is not what it should be

Because all properties and methods are visible at run-time, TypeScript has no choice but to consider those as part of the shape/structure of an instance.

[jandsu]

Hello @kitsonk and thank you for this quick response! Up to here, this is what I had understood. Nevertheless...

I would understand that I am not allowed to overwrite a private/protected name, but why force me to implement it when all I want is to implement the same contract (as in unit test stubs).

This is exactly the behavior of my workaround using the all-privates-are-optional--patent-pending pattern:

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

class MyClassMock implements MyClass {
    pubfield: number;
    private privfield1? = 0;
    // ** error ** types have separate declarations of a private property 'privfield1'
}

const foo: MyClass = {
    pubfield: 1,
    privfield1: 2 // ** error ** Property 'privfield1' is private in type 'MyClass'...
};

I come from years of rigid typing systems and the refreshing side of languages such as Javascript and Python is this "duck typing" which makes mocking a pleasure (but brings other scary issues).

To me Typescript is bringing the best of both worlds... in a kind of magical balance... Here we seem to be losing our balance IMHO.

[kitsonk]

It is dealing with the reality that there are no private or projected members. TypeScript could bury its head in the sand and ignore it, or it could face the reality and protect its users. It isn't a TypeScript thing, it is ECMAScript thing. ALL properties are public at run-time, therefore they are part of the structure, therefore in a structural typing system they count as part of the structure.

In certain use cases it is much better to create truly private data, using the language:

interface PrivateData {
  foo?: string;
}

const privateData = new WeakMap<Foo, PrivateData>();

class Foo {
  constructor() {
    privateData.set(this, {});
  }

  log() {
    console.log(privateData.get(this).foo));
  }
}

export default Foo;

In this situation, the private data is truly private and does not effect the structure of the instance.

The issue to implement the ECMAScript proposal for private fields is tracked at #9950. One can only assume once there are private fields that are truly private, they will not be considered as part of the structure of the instance.

[jandsu]

Well, again this is a matter of balance... why have implemented the private / protected keywords in Typescript if the suggestion is not to use them and to come up with a pattern such as the one you suggest?

This pattern is fine to store sensitive data such as an authentication token (to prevent access by a browser extension for example), but you will probably admit that is overkill for the standard usage of the private fields like internal state flag etc...

Those two keywords are in the language now and the question is whether they are used to make the most sense out of them or not... When I read the language design goals I have the feeling that the current behavior is trying to be too "sound"...

Indeed, even within Typescript code, you can always call Object.getPrototypeOf() and bypass compiler visibility very easily... so trying to prevent mistakes should be preferable to prevent real access.

Anyway, I will not bother you any longer with an endless discussion... Either you got my point or at least it just feeds your thoughts (the mocking use case in particular). I already apologize for being so insistent...

Whatever the outcome, I guess this point is surprising enough that it deserves a few more lines in the documentation... and this does not change the fact that you guys came to a wonderful balance with this language 🥇

[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.

[kitsonk]

First to be clear I am not a member of the core team. Some of the comments felt as if you were addressing someone who actually makes decisions.

why have implemented the private / protected keywords in Typescript if the suggestion is not to use them and to come up with a pattern such as the one you suggest?

I suspect, with the ES private members at the stage they are at, the TypeScript team would simply not have implemented them. But classes in TypeScript were implemented several years ago, even when classes in ECMAScript weren't even a certain thing. Private and protected where strong concepts from other classed based languages and were often implemented by convention in JavaScript at that point, usually denoted by an _. This choice gave some type safety for these conventions without changing the run-time behaviour of the code.

This pattern is fine to store sensitive data such as an authentication token (to prevent access by a browser extension for example), but you will probably admit that is overkill for the standard usage of the private fields like internal state flag etc...

Agreed, but it feels like you think it is an "opinion" if private and protected members are optional to be considered as part of the structural shape of the object. As Ryan pointed out, it really isn't an opinion. They effect the structural shape and it is more sound for TypeScript to consider them. I don't think it is an opinion, or striking a balance. It is more of an abject fact.

[jandsu]

Hello guys,
Thanks for your answers and your time answering my question.
Indeed the code in Ryan's example is definitely a good reason why it is the way it is. This is exactly the reason why I was asking either for a documentation improvement or... for a possible update in the language.
I hope that this doc update will help other developers understand the rationale for this decision when they will be learning Typescript.
Best regards

PS : my pattern of optional private fields is after all not so silly: making Identity.id optional forces the developer to consider that case if required

[kitsonk]

PS : my pattern of optional private fields is after all not so silly: making Identity.id optional forces the developer to consider that case if required

Side note, if during the lifecycle of a class, a private field might be undefined, I prefer to utilise | undefined versus the optional flag. In interfaces it sort of makes sense, as you are describing what the shape of an object looks like, but in instantiatable classes, that sort of Schrödinger's cat property seems less appropriate.

[jandsu]

For those who might reach this issue through a search on mocking issues, here I like better pattern than my private-is-optional one described above:

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

class MyClassMock /* does not implement MyClass this time! */ {
    pubfield: number;
}

const foo = new ClassUnderTest(new MyClassMock() as any as MyClass);

This is the kind of weird believe me! cast, but at least you can do unit testing w/o putting your private fields optional.

[unional]

A trick to quickly implement all the public interfaces:

class MyClassMock implements MyClass {
}

Use the IDE (VSCode) auto implement feature to implement the methods:

class MyClassMock implements MyClass {
  pubField: number
}

And then removing the interface:

class MyClassMock {
  pubField: number
}

Repeat that whenever you have new public properties introduced in MyClass.

[unional]

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; }
}

Regarding this, I'm not sure if this is a good example. This seems to me that it pushes the C# feature to TS a bit too far.
If we consider "true private" in JS, the other.id is not accessible.
So it is not really a valid JS.

[unional]

@jandsu regarding const foo = new ClassUnderTest(new MyClassMock() as any as MyClass);

You can simply do: const foo = new ClassUnderTest(new MyClassMock() as any);

You don't have to cast it back to MyClass because TS is duck typed.
The ClassUnderTest implementation will assume the input is an instance of MyClass, and you don't have to "test" the assignability.

[RyanCavanaugh]

Regarding this, I'm not sure if this is a good example. This seems to me that it pushes the C# feature to TS a bit too far. If we consider "true private" in JS, the other.id is not accessible.

This is hardly a C#ism. C++, Java, Swift, etc, all allow cross-instance private property access. See #10516 for discussion on this