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

module typescript public access-modifiers
person Grofit    schedule 02.04.2013    source источник

Ответы (2)


arrow_upward
182
arrow_downward

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

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

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

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

person Fenton    schedule 02.04.2013
comment
Спасибо за информацию, я предполагаю, что решение было, как вы говорите, избежать необходимости проверять контекст ключевого слова, что является позором, поскольку кажется, что это что-то, что может сбить с толку нескольких людей и действительно не имеет логической разницы в поведении того, как вы ожидаете от общественности действий, просто упрощает их реализацию. - person Grofit; 02.04.2013
comment
Спасибо за это. Спасает меня от выдергивания волос. - person Kent Aguilar; 15.11.2016
comment
Это необходимо, если вы используете модули. Если ваше приложение ориентировано на большую сторону, модули обычно являются лучшим выбором, чем создание больших пакетов / загрузка всех ваших файлов заранее. - person Fenton; 20.05.2019
comment
@Fenton Разве вы не имели в виду, что могли бы возразить, что им следовало использовать «общедоступный» вместо «экспорт»? - person Alan Evangelista; 04.03.2020
comment
@AlanEvangelista, вы, конечно, тоже могли бы спорить об этом, особенно если ваш фон был Java / C #, а не JavaScript. - person Fenton; 09.03.2020

arrow_upward
52
arrow_downward

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

  • export уже означает две разные вещи (в зависимости от того, на верхнем уровне это или нет); значит, треть, вероятно, хуже, чем добавление _2 _ / _ 3_
  • Это определенно не для упрощения реализации; дополнительная сложность public против export тривиальна. Мы уже изменили несколько ключевых слов; это не трудно.
  • Видимость по умолчанию членов класса должна быть общедоступной, чтобы соответствовать предложению класса ES6, поэтому нам нужно какое-то ключевое слово, чтобы указать «не общедоступно». Нет подходящего антонима для export (unexport ??), поэтому private - логичный выбор. Если у вас есть private, было бы безумием не выбрать public в качестве его аналога.
  • Использование export для изменения видимости во внутренних модулях - лучший вариант согласования с модулями ES6.
person Ryan Cavanaugh    schedule 02.04.2013
comment
спасибо за дополнительную информацию, я полностью согласен с публичным / частным на уровне участников, мне просто показалось странным, что их недостаточно для всех уровней доступа. Однако это личное мнение, а ключевое слово - это ключевое слово, просто хотел узнать больше. - person Grofit; 02.04.2013
comment
Я редактирую свое дерзкое заявление о простоте реализации и предлагаю +1 в качестве извинений :) - person Fenton; 04.04.2013
comment
Меня смущает первый пункт. Кто предлагает, чтобы export имел третье значение? - person gravidThoughts; 18.06.2015
comment
Кстати, я предполагаю, что кто-то неявно сделал это, но мои инстинкты TS недостаточно хороши, чтобы увидеть связь, и я хотел бы понять. (Мне действительно не нравится 5-минутное правило редактирования.) - person gravidThoughts; 18.06.2015
comment
Я согласен с некоторыми из того, что вы говорите, но я не согласен с утверждением. Нет подходящего антонима для экспорта - импорт - это антоним, и это то, что использует TypeScript, когда вы определяете экспортируемый класс, вы затем импортируете его в другой files export class User { name: string } Другой файл: import {User} from ""./the_file_path_to_the_user_class; см. раздел 3.3 документации по nativescript здесь docs.nativescript. org / angular / tutorial / ng-chapter-3 - person Adam Diament; 06.06.2016
comment
Как можно использовать import, чтобы указать, что это значение не экспортируется, подходящее использование ключевого слова? - person Ryan Cavanaugh; 06.06.2016
comment
Нет подходящего антонима для экспорта (неэкспорт ??) - подходящим антонимом для экспорта должно быть эмбарго. - person rsp; 21.05.2018
comment
сдерживать, удерживать, оставлять за собой? ничего не режет! - person DavidWainwright; 14.06.2019