Почему Typescript использует ключевое слово «экспорт», чтобы сделать классы и интерфейсы общедоступными?

Во время работы с Typescript я понял, что мои классы в модулях (используемых в качестве пространств имен) были недоступны для других классов, если я не написал exportперед ними ключевое слово, например:

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

Итак, теперь я могу использовать приведенный выше код следующим образом:

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

Однако мне просто было интересно, почему это ключевое слово используется вместо того, чтобы просто использовать publicключевое слово, которое используется на уровне метода для обозначения того, что метод или свойство должны быть доступны извне. Так почему бы просто не использовать тот же механизм, чтобы сделать классы, интерфейсы и т. Д. Внешне видимыми?

В результате получится такой код:

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

Основная причина в том, что это exportсоответствует планам для ECMAScript. Вы могли бы возразить, что «им следовало использовать« экспорт »вместо« общедоступный », но помимо того, что« экспорт / частный / защищенный »является плохо согласованным набором модификаторов доступа, я считаю, что есть тонкая разница между ними, которая объясняет это ,

В TypeScript отметка члена класса как publicили privateне влияет на сгенерированный JavaScript. Это просто инструмент времени разработки / компиляции, который вы можете использовать, чтобы остановить доступ вашего кода TypeScript к тому, чего он не должен.

С exportключевым словом JavaScript добавляет строку для добавления экспортируемого элемента в модуль. В вашем примере: here.SomeClass = SomeClass;.

Таким образом, концептуально видимость, контролируемая publicи privateпредназначена только для инструментов, тогда как exportключевое слово изменяет результат.

К ответу Стива Фентона можно добавить несколько вещей:

• export уже означает две разные вещи (в зависимости от того, на верхнем уровне или нет); это означает, что треть, вероятно, хуже, чем добавление public/private
• Это определенно не для упрощения реализации; дополнительная сложность publicvs exportтривиальна. Мы уже изменили несколько ключевых слов; это не трудно.
• Видимость членов класса по умолчанию должна быть общедоступной, чтобы соответствовать предложению класса ES6, поэтому нам нужно какое-то ключевое слово, чтобы указать «не общедоступно». Для export( unexport??) нет подходящего антонима , поэтому privateвыбор является логичным. После того, как вы это сделали private, было бы безумием не выбрать в publicкачестве его аналога
• Использование exportдля изменения видимости во внутренних модулях - лучший вариант согласования с модулями ES6.