¿Por qué TypeScript utiliza la palabra clave "exportar" para hacer públicas las clases y las interfaces?


136

Mientras incursionaba con el mecanografiado, me di cuenta de que mis clases dentro de los módulos (utilizados como espacios de nombres) no estaban disponibles para otras clases a menos que escribiera la exportpalabra clave antes de ellas, como:

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

Entonces ahora puedo usar el código anterior como este:

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

Sin embargo, me preguntaba por qué esta palabra clave se usa en lugar de solo usar la publicpalabra clave que se usa a nivel de método para indicar que un método o propiedad debe ser accesible externamente. Entonces, ¿por qué no 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{..}
}

Respuestas:


176

La razón principal es que exportcoincide con los planes para ECMAScript. Se podría argumentar que "deberían haber usado" exportar "en lugar de" público ", pero aparte de que" exportar / privado / protegido "es un conjunto de modificadores de acceso poco adaptados, creo que hay una sutil diferencia entre los dos que explica esto .

En TypeScript, marcar un miembro de la clase como publico privateno tiene efecto en el JavaScript generado. Es simplemente una herramienta de tiempo de diseño / compilación que puede usar para evitar que su código TypeScript acceda a cosas que no debería.

Con la exportpalabra clave, JavaScript agrega una línea para agregar el elemento exportado al módulo. En su ejemplo: here.SomeClass = SomeClass;.

Conceptualmente, la visibilidad controlada por publicy privatees solo para herramientas, mientras que la exportpalabra clave cambia la salida.


1
Gracias por la información, supongo que la decisión fue como usted dice para evitar tener que verificar el contexto de la palabra clave, lo cual es una pena, ya que parece que es algo que hará tropezar a algunas personas y realmente no tiene una diferencia lógica en el comportamiento. a cómo espera que actúe el público, solo facilita su implementación.
Grofit

Gracias por esto. Me ahorra el pelo tirando.
Kent Aguilar

1
Es necesario si está utilizando módulos. Si su aplicación es hacia el lado más grande, los módulos suelen ser una mejor opción que crear grandes paquetes / cargar todos sus archivos por adelantado.
Fenton

@Fenton ¿No quisiste decir "podrías argumentar que deberían haber usado 'público' en lugar de 'exportar'?
Alan Evangelista

@AlanEvangelista ciertamente también podría argumentarlo de esa manera, especialmente si su fondo era Java / C # en lugar de JavaScript.
Fenton

49

Algunas cosas para agregar a la respuesta de Steve Fenton:

  • export ya significa dos cosas diferentes (dependiendo de si está en el nivel superior o no); lo que significa que un tercio es probablemente peor que agregar public/private
  • Definitivamente no es para facilitar la implementación; La complejidad adicional de publicvs exportes trivial. Ya hemos cambiado las palabras clave en un montón; no es dificil.
  • La visibilidad predeterminada de los miembros de la clase debe ser pública para alinearse con la propuesta de clase de ES6, por lo tanto, necesitamos alguna palabra clave para indicar "no público". No hay un antónimo adecuado para export( unexport??), por lo que privatees la opción lógica. Una vez que lo haya hecho private, sería un poco loco no elegir publiccomo su contraparte
  • El uso de exportpara modificar la visibilidad en los módulos internos es la mejor alineación con los módulos ES6

1
gracias por la información adicional, estoy completamente de acuerdo con el ser público / privado a nivel de miembro, me pareció extraño que no sea suficiente para todos los niveles de acceso. Sin embargo, esta es una opinión personal y una palabra clave es una palabra clave, solo quería saber más.
Grofit

55
Redacto mi descarada declaración sobre la facilidad de implementación y ofrezco un +1 como disculpa :)
Fenton

2
Estoy de acuerdo con algo de lo que está diciendo, pero no estoy de acuerdo con la afirmación "No hay un antónimo apropiado para exportar" - "importar" es el antónimo, y es lo que utiliza TypeScript, cuando define una clase exportable, entonces impórtelo a otros archivos export class User { name: string } Otro archivo: import {User} from ""./the_file_path_to_the_user_class; consulte la sección 3.3 de los documentos nativescript
Adam Diament

3
¿Cómo usar importpara indicar "este valor no se exporta " sería un uso adecuado de la palabra clave?
Ryan Cavanaugh

55
"No hay un antónimo apropiado para exportar (¿no exportar?"), Un antónimo apropiado para la exportación debería ser el embargo.
rsp
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.