Google Dart видимость методов и свойств

Question

Чтобы избежать некоторых недоразумений, я знаю, что Google Dart обрабатывает вещи на уровне библиотеки и что частные свойства и методы можно идентифицировать с помощью префикса подчеркивания.

Является ли это еще актуальным с 2017 года? Существуют ли какие-либо планы по добавлению ключевых слов на уровне объектов, таких как: частный, защищенный или открытый?

Я просто не хочу делать что-то случайное, но я скорее заинтересован в лучших практиках. Я вижу это: если я не хочу, чтобы класс один видел, что второй класс, то оба должны быть в разных библиотеках, тогда эти библиотеки являются частью более крупного пакета.

библиотеки = приватность между классами пакетов = приватность между файлами

насчет мелкозернистого контроля конфиденциальности? Я имею в виду, может быть, есть одна вещь, которую я хочу частным. Как использовать видимость при использовании наследования? Я имею в виду, что защищенные ключевые слова могут быть действительно ценными.

Вот небольшой пример в одном файле:

class one { 
    int n = 1; 

    one() { 
    var test = new two(n); 
    print(test.showNumber()); 
    } 
} 

class two { 
    int n = 2; 

    two(n) { 
    this.n += n; 
    } 

    int showNumber() { 
    return n; 
    } 
} 

Как она стоит сейчас, оба класса могут делать то, что они хотят.

Answer 1

Dart по-прежнему имеет только конфиденциальность на уровне библиотеки.

Конфиденциальность на уровне библиотек с идентификаторами, начинающимися с подчеркивания, также применяется во время выполнения.

Анализатор предоставляет некоторые дополнительные функции во время статического анализа, которые, однако, игнорируются во время выполнения.

По соглашению также библиотеки внутри lib/src считаются частными и должны быть импортированы из других пакетов. linter, плагин для анализатора уведомляет о нарушениях. Кажется, это часть самого анализатора.

Пакет meta содержит некоторые аннотации, которые поддерживаются анализатором.

• @protected производит предупреждение, если публичные члены ссылаются кодом из других библиотек, не является в подклассах.

• @visibleForTesting производит предупреждение, если открытые члены являются ссылки на код, который не находится в пределах test каталога (одного и того же пакета, я предполагаю) Не уверен, если анализатор фактически предупреждает о нарушениях пока, в противном случае это планируется сделать.

Насколько я помню, есть некоторые проблемы для большего количества правил, но еще не реализованы.

Из комментария @ ЛРН в поле ниже

Одной из причин существующей конструкции является то, что Dart позволяет динамические вызовы, даже в сильном режиме. Это означает, что o.foo() не может быть отклонен на основе «конфиденциальности на уровне класса» без сохранения и проверки дополнительной информации во время выполнения.В условиях конфиденциальности на основе библиотеки/лексики абсолютно ясно, разрешено ли o.foo() или o._foo() (это всегда так, что последний может ссылаться только на имя _foo той же библиотеки). Если у Дарта было только статическое разрешение идентификаторов, тогда он мог бы использовать статическую информацию (например, объявление private) для отклонения во время компиляции без служебных затрат времени исполнения.