Feature Request: access inherited protected member in subclasses branched from a base class where the protected member is defined in the base class

Search Terms

• typescript protected class branch
• typescript access protected in sibling

Suggestion

Allow subclasses to access inherited protected members across instances of the subclasses.

Use Cases

There are use cases when we'd like subclass branches that inherit a protected member to be able to access the inherited protected member across instances of the branched subclasses.

There are also use cases where subclasses cause invariants by narrowing the type of an inherited member, which we should be able to guard against at compile time.

Examples

This PlayGround example doesn't work, to illustrate the current limitation.

I have a use case, where I have a TreeNode sort of class with protected properties, then I have subclasses of the TreeNode, one called Mesh, and the other called Scene, where the Scene needs to traverse the tree to run logic using the protected members (thus reading the protected member of all instances of Mesh), but TypeScript won't allow it.

The code that is Scene-specific lives inside the Scene class (because that makes sense).

To make it work, I'd have to move that code into the common base class TreeNode, but then it will be messy and un-organized.

FWIW, I have the same problem in my runtime JS class implementation, lowclass, which I'm now thinking about solving with an option.

In general, I think that well-designed classes will benefit from this feature, and that poor coding practices will lead to issues with this (which is why the compiler should catch the problems in those cases). (f.e. if base class specifies a protected member of type number | string, and a sibling subclass changes it to number, then the compiler can obviously catch a problem when another sibling subclass wants to read from the other one and hasn't narrowed the type to number as well.)

implementation ideas

A subset of the following ideas might do the trick:

• a compiler option to allow or disallow this feature

• We can detect invariants at compile time. From this post,

  Other sibling classes might add invariants that your class doesn't know about

  In the above example, if the types agree in the subclasses, we can let it work, and throw a runtime error only when there is a type mismatch. But suppose in my above example that Scene and Mesh don't modify the inherited protected type, and only read it or set it. The compiler can easily ensure that things are okay.

• disallow subclasses from modifying types of inherited members

  • perhaps a compiler option for this
  • this can prevent subclasses of subclasses of subclasses from being so far removed (not resembling their base class at all), by forcing subclasses to add new features on new properties instead of existing ones

• Follow the same rules as public, which is not guarded against this. An invariant problem can happen across siblings inheriting and modifying the member from the base class, yet the compiler will not stop it.

• another compiler option

Mainly, my reasoning above is that there is a way to make this work with some semantics and/or options, and it is okay if those are specific to TypeScript. We won't invent new wheels, but we can improve existing wheels instead of copying them.

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code not sure
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

Related Issues:

• https://github.com/Microsoft/TypeScript/issues/1
• https://github.com/Microsoft/TypeScript/issues/8512
• https://github.com/Microsoft/TypeScript/issues/10637
• https://github.com/Microsoft/TypeScript/issues/11278
• https://github.com/Microsoft/TypeScript/issues/11832
• https://github.com/Microsoft/TypeScript/issues/22900

Inizia esaminando le issue correlate collegate e gli esempi di Playground per comprendere le regole esistenti dei protected members e la semantica proposta per l’accesso tra classi sorelle. Un contributo completo richiederebbe un design concordato, un comportamento del type-checking documentato e test che coprano i casi di ereditarietà e narrowing descritti qui.