Class implementing class should ignore non-public members

[SergioMorchon]

Example:

class Class1 {
    private privateMember;
}

class Class2 implements Class1 {
}

The compiler says:
Property 'privateMember' is missing in type 'Class2'

But obviusly a private member never will be part of an interface.

[danquirk]

This has come up before. It's technically by design but it does feel strange. We allow classes to implement other classes which works fine when the class doesn't have private members. But obviously a big motivation for using classes is to encapsulate private state and expose it publicly some other way, at which point classes can't implement other classes in a useful way. We could consider whether the more useful design for this feature is for implementing a class to only mean implementing the public surface area.

As a concrete example, this feature is basically trying to let you avoid writing this:

interface MyInterface {
   foo: string;
}
class Class1 implements MyInterface {
    private data: number;
    foo: string;
}
class Class2 implements Class1 {
   private otherData: number;
   foo: string;
   bar: string;
}

by instead just using Class1 as the canonical interface specification and contract rather than manually factoring out an interface definition. Obviously if Class1 has privates there's no interface you would've manually factored out which could've also had privates.

[mhegazy]

how is that different from this:

class Class1 {
    private data: number;
    foo: string;
}

interface Class1Interface extends Class1 {
}

class Class2 implements Class1Interface {
}

// Error TS2420: Class 'Class2' incorrectly implements interface 'Class1Interface'.
//    Property 'data' is missing in type 'Class2'.

and this one is intentionally by design.

[danquirk]

It's not different, it's the same problem. What is the point of enabling these types to extend a class if a common case makes it not actually useful? What is the value of including the privates? Does it enable something interesting or does it mostly just stop the feature from being generally useful?

[SergioMorchon]

An Interface is the public face of an entity, and I thinkt that it shouldn't expose it's non-public members. It feels strange and, the worst thing, it breaks the visibility of the child class by showing its protected and private members.

[mhegazy]

@SergioMorchon, One think to clarify that this behavior is an intentional design decisions. Since TS type system is structural, you could have easily duplicated the class structure in an interface, or even dropped the whole implements class1 part and your two classes would be still be assignable.

@danquirk, i would be interested to know if anyone is using this pattern for non-implementable interfaces. i agree it is probably less useful, but i can not tell if any one depends on it.

[SergioMorchon]

I can't figure what are the benefits, and it can be confusing...
Becasuse:
If you implement a class with its private members, only that implementation will know about them.
If you extend it, it won't be necessary to implement those privates (because of encapsulation).

BUT if you use the keyword "implements" instead of extend, which I expected to be even more laxed tan inheriting (because if I inherit, i can Access protecteds, but an interface "is" public-only), I will be forced to implement private members that are unnecesarry aoutside the class, because anyone will be able to use them! So... Why?

[NoelAbrahams]

Possible duplicate of #471

[SergioMorchon]

Yes, it's duplicated.

Thanks for referencing the original!!