You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[ts] 'private' modifier cannot appear on a type member. #25163
private means it should only be visible to members declared on the same type--but since interface members don't have implementations, there's no way to reference the private property. So it's just not allowed.
Reacted by Masoud G Sarini, José Angel Peñarroche Delgado, ranjeetsih, Corvin and Haruki Kondo
It looks like this is a question rather than a bug report. This issue tracker is for tracking bugs and active work on TypeScript itself, rather than a general forum for programmers using TypeScript to get help or ask questions.
You can ask questions on sites like Stack Overflow. We are not able to provide one-on-one support on the issue tracker. Next time, please read the issue template carefully - it has important information on what kinds of reports can be acted on here, as well as links to useful TypeScript resources. Thanks!
I think there is a bit of confusion that leads up to this error. If the members defined in the class are private, and these same members are used in the interface, TS will not compile and complain that these members are not set as private.
Class 'TestClass' incorrectly implements interface 'IInterface'.
Property 'memberOne' is private in type 'TestClass' but not in type 'IInterface'.
So if setting access modifiers on interfaces is not possible why does TS give this sort of error which implies there are? I'm guessing the overall idea is to not add private members in an interface, and if that's the case, maybe TS could offer an error to imply something along those lines instead?
Reacted by Saninn Salas Diaz, quisi.do, S E R A Y A, Simon Siefke, Jolo, Guber, Tarik Chakur, Jordi Nebot, ffflick-gh, Jonathan Buchner and 108 more
Reacted by ThaJay, Awaji-mitop N. Gilbert, Nikita PB and omaksi
Interfaces define "public" contracts and as such it doesn't make sense to have protected or private access modifier on interfaces, which are more of a, let's call it, implementation detail. As such you can't do what you want with an interface.
What about protected? Seems like this is obviously needed (as opposed to private).
I'm using types for mixin classes (it is inevitable to have to step around the class system and use types to make them work fully). And I'd like to be able to specify protected in some interfaces which I'm using along Constructor types to create the types minimal types of expected classes being passed to the mixins.
Reacted by Varun Kumar, Jakub Boháček, Yuya Sasaki, HuiiBuh, Haytham Halimeh and Brendan Mosby
For example, it is necessary to use interfaces/types (and not class) in order to make a mixin class understand what methods a base class might possibly have:
typePossibleCustomElement<TextendsHTMLElement>=T&{protectedconnectedCallback?(): void// contrived exampledisconnectedCallback?(): voidadoptedCallback?(): voidattributeChangedCallback?(name: string,oldVal: string|null,newVal: string|null): void}// This is a mixin only for Web Components! :)exportfunctionWithUpdateMixin<TextendsConstructor<HTMLElement>>(Base: T){classWithUpdateextendsBaseasunknownasConstructor<PossibleCustomElement<HTMLElement>>{protectedconnectedCallback(){if(super.connectedCallback)super.connectedCallback()}}}
And so you see, I want to be able to define certain possibly-existing method/properties from the Base class (which is constrained by type T), and if any of those methods are protected, then now they will all be public because there's no way to specify it in the mixin.
For sake of argument, let's imagine that connectedCallback is a protected method in some subclasses of HTMLElement; suppose this is a convention in HTML world (I know, it actually isn't, this is just an example). Then it'd be convenient if all I had to do was add the protected keyword for it to just work.
Reacted by Masoud G Sarini, Felipe Freitas, harshagarwal00, Haruki Kondo and ThaJay
Here's what we can do to make a type with access modifiers, although it emits an unused runtime class (based on some actual code I have, much omitted):
typeConstructor<T=object,Aextendsany[]=any[]>=new(...a: A)=>TfunctionConstructor<T=object>(Ctor: Constructor<any>){return(Ctorasunknown)asConstructor<T>}// using a `class` instead of `interface` or `type`!classPossiblyWebComponent{protectedchildConnectedCallback?(child: Element): voidprotectedchildDisconnectedCallback?(child: Element): voidprotected_isPossiblyDistributedToShadowRoot?: booleanprotected_distributedParent?: TreeNode}functionAwesomeMixin<TextendsConstructor>(Base: T){constParent=SomeOtherMixin(Constructor<PossiblyWebComponent>(Base))classAwesomeextendsParent{protectedchildConnectedCallback(child: Element){if(super.connectedCallback)super.connectedCallback(child)}// ...}returnAwesomeasConstructor<Awesome&InstanceType<T>>}
It is possible to run the code through some Babel or Webpack plugin to snip unused code.
EDIT: Or maybe just use declare to prevent the runtime output. I almost forgot about that.
Reacted by Jé, a11delavar, LeePieMee, Nikita, Felipe Freitas, Robby and Teshan Liyanage
Activity
j-oliveras commentedon Jun 22, 2018
You can only use
privateinside a class.RikkiGibson commentedon Jun 22, 2018
private means it should only be visible to members declared on the same type--but since interface members don't have implementations, there's no way to reference the private property. So it's just not allowed.
RyanCavanaugh commentedon Jun 22, 2018
It looks like this is a question rather than a bug report. This issue tracker is for tracking bugs and active work on TypeScript itself, rather than a general forum for programmers using TypeScript to get help or ask questions.
You can ask questions on sites like Stack Overflow. We are not able to provide one-on-one support on the issue tracker. Next time, please read the issue template carefully - it has important information on what kinds of reports can be acted on here, as well as links to useful TypeScript resources. Thanks!
MutableLoss commentedon Oct 27, 2018
I think there is a bit of confusion that leads up to this error. If the members defined in the class are private, and these same members are used in the interface, TS will not compile and complain that these members are not set as private.
Using the above will yield the following error:
So if setting access modifiers on interfaces is not possible why does TS give this sort of error which implies there are? I'm guessing the overall idea is to not add private members in an interface, and if that's the case, maybe TS could offer an error to imply something along those lines instead?
andykais commentedon Feb 1, 2019
do we currently have any way to mark interface properties as protected or private? Currently this is the best I can do:
though this isnt a great solution because if
TestInterfacehad extra properties, no error would be thrown if they were missing fromTestClasstakahser commentedon Feb 14, 2019
I agree with 3desprit
Why is this happening?
edit
Apparently,
see original post on SO
trusktr commentedon Jun 30, 2019
What about
protected? Seems like this is obviously needed (as opposed to private).I'm using types for mixin classes (it is inevitable to have to step around the
classsystem and use types to make them work fully). And I'd like to be able to specifyprotectedin some interfaces which I'm using along Constructor types to create the types minimal types of expected classes being passed to the mixins.trusktr commentedon Jun 30, 2019
For example, it is necessary to use interfaces/types (and not
class) in order to make a mixin class understand what methods a base class might possibly have:And so you see, I want to be able to define certain possibly-existing method/properties from the
Baseclass (which is constrained by typeT), and if any of those methods are protected, then now they will all be public because there's no way to specify it in the mixin.For sake of argument, let's imagine that
connectedCallbackis a protected method in some subclasses ofHTMLElement; suppose this is a convention in HTML world (I know, it actually isn't, this is just an example). Then it'd be convenient if all I had to do was add theprotectedkeyword for it to just work.trusktr commentedon Jun 30, 2019
Here's what we can do to make a type with access modifiers, although it emits an unused runtime class (based on some actual code I have, much omitted):
It is possible to run the code through some Babel or Webpack plugin to snip unused code.
EDIT: Or maybe just use
declareto prevent the runtime output. I almost forgot about that.Leandro-Hespanhol commentedon Apr 11, 2022
I think the solution lies in 'getters', here is an example:
That way you can implement an interface and still keep class attributes protected.
Autumnlight02 commentedon Aug 20, 2022
Leandro Hespanhol (@Leandro-Hespanhol) Thank you!
ThaJay commentedon Mar 13, 2023
Type script seems more and more time consuming and convoluted as I learn it on an ever deepening level