Pourquoi Typescript utilise-t-il le mot clé "export" pour rendre les classes et les interfaces publiques ?

Question

En m'amusant avec Typescript, j'ai réalisé que mes classes dans les modules (utilisés comme espaces de noms) n'étaient pas disponibles pour les autres classes, à moins que j'écrive l'attribut export mot-clé devant eux, comme :

module some.namespace.here
{
   export class SomeClass{..}
}

Donc maintenant je peux utiliser le code ci-dessus comme ceci :

var someVar = new some.namespace.here.SomeClass();

Cependant, je me demandais juste pourquoi ce mot-clé est utilisé plutôt que d'utiliser simplement la fonction public qui est utilisé au niveau de la méthode pour signifier qu'une méthode ou une propriété doit être accessible de l'extérieur. Alors pourquoi ne pas utiliser ce même mécanisme pour rendre les classes, les interfaces, etc. visibles de l'extérieur ?

Cela donnerait un code résultant comme :

module some.namespace.here
{
   public class SomeClass{..}
}

Answer 1

La raison principale est que export correspond aux plans pour ECMAScript. On pourrait dire qu'ils auraient dû utiliser "export" au lieu de "public", mais outre le fait que "export/privé/protégé" est un ensemble de modificateurs d'accès mal adapté, je pense qu'il y a une différence subtile entre les deux qui explique cela.

En TypeScript, le fait de marquer un membre de classe comme public o private n'a aucun effet sur le JavaScript généré. Il s'agit simplement d'un outil de conception / compilation que vous pouvez utiliser pour empêcher votre code TypeScript d'accéder à des éléments qu'il ne devrait pas.

Avec le export le JavaScript ajoute une ligne pour ajouter l'élément exporté au module. Dans votre exemple : here.SomeClass = SomeClass; .

Donc conceptuellement, la visibilité est contrôlée par public y private ne sert qu'à l'outillage, tandis que le export modifie la sortie.

Answer 2

Quelques éléments à ajouter à la réponse de Steve Fenton :

• export déjà signifie deux choses différentes (selon qu'il est au niveau supérieur ou non) ; lui faire signifier une troisième chose est probablement pire que d'ajouter public / private
• Ce n'est certainement pas pour rendre la mise en œuvre plus facile ; la complexité supplémentaire de la public vs export est trivial. Nous avons déjà changé plusieurs fois de mots-clés ; ce n'est pas difficile.
• La visibilité par défaut des membres de la classe doit être public pour s'aligner sur la proposition de classe ES6, nous avons donc besoin d'un mot clé pour indiquer "non public". Il n'y a pas d'antonyme approprié à export ( unexport ? ?), donc private est le choix logique. Une fois que vous avez private il serait un peu fou de ne pas choisir public comme son homologue
• Utilisation de export pour modifier la visibilité dans les modules internes est l'alignement le plus probable avec les modules ES6