Почему 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{..}
}

Ответы

Ответ 1

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

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

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

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

Ответ 2

Несколько слов, чтобы добавить к Стиву Фентону ответ:

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

Ответ 3

Собственно, это для совместимости Node.js.

Если вы посмотрите на преобразованный код для:

export function foo(){
}

вы получаете:

function foo(){
}
exports.foo = foo;

который является синтаксисом Node.