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
e.g. then you could expose a class that can only be used in type annotations, or for its static methods (which could include factory methods that call out to the constructor).
The text was updated successfully, but these errors were encountered:
I think this issue is slightly misconceived. Indeed, I had previously understood @private on a class to mean that all references to the class should cause a visibility error, but I'm getting reports that the actual current behavior is that there's no way to make a class (i.e. type refs or static methods) private, and that @private on the class only applies to calling the constructor.
But the gist is still correct, these are two separate concepts and we need to be able to express then both.
Visibility checks now respect visibility annotations on ES6 class constructors.
Visibility annotations on constructors refer to the invocability of the constructor (including use in extends clauses). It does not effect the ability to reference the class in any other context (e.g. instanceof, assignment, parameter passing). The variable used to reference the constructor is irrelevant to the check, only the type matters.
Constructor visibility is selected in descending preference by: (1) annotation directly on the definition, (2) annotation in the @fileoverview, (3) @public by default. It is not inherited from superclass definitions. It is not inferred from class definitions.
e.g. then you could expose a class that can only be used in type annotations, or for its static methods (which could include factory methods that call out to the constructor).
The text was updated successfully, but these errors were encountered: