módulo - ¿Por qué TypeScript usa la palabra clave "export" para hacer públicas las clases e interfaces?

Mientras experimentaba con Typescript, me di cuenta de que mis clases dentro de los módulos (usados como espacios de nombres) no estaban disponibles para otras clases a menos que escribiera la palabra clave export antes de ellas, como:

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

Entonces ahora puedo usar el código anterior así:

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

Sin embargo, solo me preguntaba por qué se usa esta palabra clave en lugar de simplemente usar la palabra clave public, que se usa a nivel de método para indicar que un método o propiedad debe ser accesible externamente. Entonces, ¿por qué no simplemente usar este mismo mecanismo para hacer que las clases e interfaces, etc., sean visibles externamente?

Esto daría un código resultante como:

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

Respuesta #1

La razón principal es que export coincide con los planes para ECMAScript. Se podría argumentar que "deberían haber usado "export" en lugar de "public", pero aparte de que "export/private/protected" es un conjunto de modificadores de acceso mal combinado, creo que hay una diferencia sutil entre los dos que explica esto.

En TypeScript, marcar un miembro de clase como public o private no tiene ningún efecto en el JavaScript generado. Es simplemente una herramienta de diseño/tiempo de compilación que puedes usar para evitar que tu código TypeScript acceda a cosas a las que no debería.

Con la palabra clave export, JavaScript agrega una línea para añadir el elemento exportado al módulo. En tu ejemplo: here.SomeClass=SomeClass;.

Entonces conceptualmente, la visibilidad controlada por public y private es solo para herramientas, mientras que la palabra clave export cambia la salida.

Respuesta #2

Algunas cosas que añadir a la respuesta de Steve Fenton:

• export ya significa dos cosas diferentes (dependiendo de si está en el nivel superior o no); hacer que signifique una tercera probablemente es peor que agregar public/private
• Definitivamente no es para facilitar la implementación; la complejidad añadida de public frente a export es trivial. Ya hemos cambiado palabras clave varias veces; no es difícil.
• La visibilidad predeterminada de los miembros de la clase debe ser pública para alinearse con la propuesta de clases de ES6, por lo tanto necesitamos alguna palabra clave para indicar "no pública". No existe un antónimo adecuado para export (unexport??), así que private es la elección lógica. Una vez que tienes private, sería algo insensato no elegir public como su contraparte
• El uso de export para modificar la visibilidad en módulos internos es la alineación de mejor estimación con los módulos ES6