Perché Typescript usa la parola chiave "export" per rendere pubbliche le classi e le interfacce?

Mentre mi dilettavo con Typescript mi ​​sono reso conto che le mie classi all'interno dei moduli (usate come spazi dei nomi) non erano disponibili per altre classi a meno che non avessi scritto la exportparola chiave prima di loro, come:

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

Quindi ora posso usare il codice sopra in questo modo:

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

Tuttavia, mi stavo solo chiedendo perché questa parola chiave sia utilizzata anziché usare la publicparola chiave utilizzata a livello di metodo per indicare che un metodo o una proprietà dovrebbe essere accessibile esternamente. Quindi perché non usare questo stesso meccanismo per rendere le classi, le interfacce ecc. Visibili esternamente?

Ciò darebbe il codice risultante come:

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

Il motivo principale è che exportcorrisponde ai piani per ECMAScript. Si potrebbe sostenere che "avrebbero dovuto usare" export "anziché" public ", ma a parte" export / private / protetto "essendo un insieme scarsamente abbinato di modificatori di accesso, credo che ci sia una sottile differenza tra i due che spiega questo .

In TypeScript, contrassegnare un membro della classe come publico privatenon ha alcun effetto sul JavaScript generato. È semplicemente uno strumento di progettazione / compilazione che puoi usare per impedire al tuo codice TypeScript di accedere a cose che non dovrebbe.

Con la exportparola chiave, JavaScript aggiunge una riga per aggiungere l'elemento esportato al modulo. Nel tuo esempio: here.SomeClass = SomeClass;.

Concettualmente, la visibilità è controllata da publiced privateè solo per gli strumenti, mentre la exportparola chiave cambia l'output.

Alcune cose da aggiungere alla risposta di Steve Fenton:

• export significa già due cose diverse (a seconda che sia al livello più alto o meno); fare in modo che un terzo sia probabilmente peggio che aggiungere public/private
• Non è sicuramente per rendere più semplice l'implementazione; la complessità aggiunta di publicvs exportè banale. Abbiamo già cambiato le parole chiave in un gruppo; non è difficile.
• La visibilità predefinita dei membri della classe deve essere pubblica per allinearla con la proposta di classe ES6, pertanto abbiamo bisogno di alcune parole chiave per indicare "non pubblico". Non c'è un antonimo adatto a export( unexport??), quindi privateè la scelta logica. Una volta che hai private, sarebbe un po 'folle non scegliere publiccome controparte
• L'uso di exportper modificare la visibilità nei moduli interni è l'allineamento migliore con i moduli ES6