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

En barbotant 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'aie écrit le exportmot - clé avant elles, tel que:

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

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

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

Cependant, je me demandais simplement pourquoi ce mot-clé est utilisé par opposition à la simple utilisation du publicmot - clé 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 simplement utiliser ce même mécanisme pour rendre les classes et les interfaces, etc. visibles de l'extérieur?

Cela donnerait un code résultant comme:

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

La raison principale est que cela exportcorrespond aux plans d'ECMAScript. Vous pourriez affirmer qu '"ils auraient dû utiliser" export "au lieu de" public ", mais à part" export / privé / protégé "étant un ensemble de modificateurs d'accès mal assorti, je pense qu'il y a une différence subtile entre les deux qui explique cela .

Dans TypeScript, marquer un membre de classe comme publicou privaten'a aucun effet sur le JavaScript généré. C'est simplement un outil de conception / compilation que vous pouvez utiliser pour empêcher votre code TypeScript d'accéder à des choses qu'il ne devrait pas.

Avec le exportmot - clé, 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 publicet privateest juste pour l'outillage, alors que le exportmot - clé change la sortie.

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

• export signifie déjà deux choses différentes (selon que c'est au plus haut niveau ou non); ce qui signifie qu'un tiers est probablement pire que d'ajouter public/private
• Ce n'est certainement pas pour faciliter la mise en œuvre; la complexité supplémentaire de publicvs exportest triviale. Nous avons déjà changé de mots-clés autour d'un tas; ce n'est pas difficile.
• La visibilité par défaut des membres de la classe doit être publique 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é pour export( unexport??), c'est donc privatele choix logique. Une fois que vous l'avez private, il serait un peu fou de ne pas choisir publiccomme son homologue
• L'utilisation de exportpour modifier la visibilité dans les modules internes est le meilleur alignement avec les modules ES6