Что команда TypeScript думает о синтаксисе и использовании префикса символа / символа?

Я лично считаю, что это выглядит ужасно , но, очевидно, есть технические ограничения (использование должно определять видимость по причинам, которые я не полностью понимаю).

Было бы грустно видеть, что TypeScript теряет текущий частный / защищенный синтаксис, который намного чище и совместим с рядом других языков. Возможно ли это? Есть ли альтернативы?

В дополнение к этому, ведутся разговоры о возможном переключении символов # и @ (т. Е. С использованием # для декораторов), что, очевидно, также повлияет на TypeScript. .

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

обычаи должны определять видимость по причинам, которые я не полностью понимаю

В основном потому, что вам нужно определить на сайте использования, как искать свойство, поскольку для этого нужен другой алгоритм поиска, чтобы дочерние классы могли повторно использовать одни и те же частные имена без необходимости «знать» о частных свойствах предка.

Одним из преимуществ предложенного синтаксиса является то, что вы можете опустить this и просто использовать #field напрямую. Кроме того, сигил может быть заменен декораторами (https://github.com/tc39/proposal-private-fields/issues/32), и вместо этого будет использоваться @ , поэтому вы должны использовать @field , как и Руби. Вы все еще считаете этот синтаксис уродливым?

Я не думаю, что люди будут довольны решением, не основанным на "закрытых" ключевых словах.

Я не вижу хорошего способа сделать это, поддерживая общий eval как это делает JavaScript - конкретный токен допускает некоторую дифференциацию и позволяет поддерживать частное состояние, которое не основано на системе статических типов, как в TypeScript. . Мы обсудили ряд альтернатив синтаксиса на https://github.com/tc39/proposal-private-fields/issues/14 , и я не считаю, что текущий синтаксис TypeScript может работать должным образом все время в полностью общая среда JS.

В основном потому, что вам нужно определить на сайте использования, как искать свойство, поскольку для этого нужен другой алгоритм поиска, чтобы дочерние классы могли повторно использовать одни и те же частные имена без необходимости «знать» о частных свойствах предка.

Хотел бы я знать больше о том, как работает JavaScript внутри. Я думал, что это будет работать так, как описано здесь и здесь , но, видимо, нет. Мне все еще трудно поверить, что это могло бы существенно повлиять на производительность, но нет цифр для сравнения.

Вы все еще считаете этот синтаксис уродливым?

По сути, да. Более того, я считаю, что это несовместимо с остальным синтаксисом JavaScript, а также несовместимо со многими другими языками:

| Язык | Синтаксис | Примечания |
| --- | --- | --- |
| C # | частный int x; | |
| C ++ | частный:
int x; | |
| Java | частный int x; | |
| PHP | частный $ x; | |
| Python | __x | "без комментариев" |
| Рубин | частный
def метод
# ...
конец | Это метод, но поля являются частными
по умолчанию думаю. |
| TypeScript | частный x; | |
| Visual Basic | Частный x как целое число | |

Все вышеперечисленные языки, кроме _один_, используют ключевое слово private , и кажется, что Python все равно не имеет "правильного" частного состояния.

За исключением Python (опять же), ни одно из объявлений полей форматирования языков или доступа к полям по-разному в зависимости от видимости, и все они допускают новые модификаторы видимости, если это когда-либо потребуется.

Я также считаю, что и # и @ лучше подходят для таких вещей, как декораторы, которые ( по словам Кевина ) «синтаксически« вне »императивного потока».

Я не вижу хорошего способа сделать это, поддерживая общий eval, как это делает JavaScript.

Можно ли объяснить эту проблему непрофессионалами? (возможно, в https://github.com/tc39/proposal-private-fields/issues/14)

Было бы неплохо собрать список этих проблем с примерами в одном месте, чтобы было на что ссылаться.

Мне все еще трудно поверить, что это могло бы существенно повлиять на производительность, но нет цифр для сравнения.

Было бы, если вы хотите, чтобы он был действительно приватным, а не просто соглашением, как в TypeScript. Всякий раз, когда вы ищите свойство в JavaScript, процесс выглядит примерно так:

1. Посмотрите на экземпляр на предмет собственной собственности.
2. Если собственной собственности нет, посмотрите на прототип собственной собственности.
3. Поднимайтесь по цепочке прототипов до тех пор, пока не будет найдено ни одного свойства.
4. Если обнаружен, сделайте операцию с дескриптором свойства (записываемый, получаемый, устанавливаемый, настраиваемый)
5. Если не найден и не прочитан, вернуть undefined или записать, установить значение как собственное свойство, если оно не запечатано или не заморожено.

Теперь, когда у частных лиц нет шаблона в имени, у вас не будет собственных свойств, у вас будет что-то вроде собственных частных свойств, которые не будут подниматься по цепочке прототипов. Затем вам придется искать их там также для каждой операции, которая может получить доступ к частным свойствам, потому что вы не можете быть уверены, к какой из них идет ссылка. Поиск его обычным способом и только тогда, если он не найден в частных лицах, может быть очень опасным, потому что что, если вы нашли что-то в цепочке прототипов, но есть еще и частная версия?

Самая большая проблема заключается в том, что классы JavaScript все еще используются неправильно. По сути, они являются синтаксическим сахаром для прототипных функций конструктора наследования. У меня возникла одна мысль, которую я попытаюсь добавить в tc39 / offer-private-fields # 14.

Можно ли объяснить эту проблему непрофессионалами?

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

class Foo {
    private foobar: string;
    baz() {
        const p = 'foo' + 'bar';
        console.log(this[p]);
    }
}

Или любое использование структур типа eval . Вы можете выбрать не поддерживать такие вещи, как доступ к индексу для частных лиц или отсутствие поддержки eval, но тогда «зачем беспокоиться». Практически все это так или иначе было указано в предложении, но люди по-прежнему «но мне нравится личное» 😁.

у вас не было бы собственной собственности, у вас было бы что-то вроде собственной частной собственности

Если бы у вас был единственный набор свойств с элементом visibility в дескрипторе, я думаю, проблема в том, что если бы свойство не существовало в текущем объекте, вы бы не знали, подниматься или нет цепочка прототипов.

Если для этого потребуется переписать сайт звонка, вы никогда не сможете поддерживать такие вещи, как ...

AFAIK, это все равно не будет поддерживаться ( ref ).

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

но люди по-прежнему "но я люблю личное"

Я пытаюсь не быть одним из этих людей и разбираться в проблемах, но предлагаемый синтаксис просто доставляет мне дискомфорт. знак равно

Хорошо, я думаю, что теперь понимаю случай eval / rewrite. Сайты использования внутри класса будут переписаны, чтобы указать видимость на основе объявленных свойств, и это было бы невозможно, если бы они не были простыми поисками.

Если бы у вас был единственный набор свойств с элементом видимости в дескрипторе, я предполагаю, что проблема в том, что если бы свойство не существовало в текущем объекте, вы бы не знали, подниматься ли вверх по цепочке прототипов.

Хм. Но если он не существует в текущем классе, то разве он по определению не является частным? Если это так, ему все равно придется продвигаться вверх по цепочке прототипов (как при обычном поиске общедоступных свойств). Для доступа private не будет никакой дополнительной работы.

(Возможно, я упускаю что-то очевидное)

Но если он не существует в текущем классе, то разве он по определению не является частным? Если это так, ему все равно придется продвигаться вверх по цепочке прототипов (как при обычном поиске общедоступных свойств).

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

@ glen-84 Оба упомянутых вами сообщения указывают на проблемы с частным состоянием без подписи. У вас есть идеи по решению этих проблем? Я думаю, что усложнение цепочки поиска было бы рискованным с точки зрения совместимости, затруднило бы реализацию JavaScript с хорошей производительностью (возможно, сделало бы существующие программы медленнее), было бы практически невозможно согласовать с прокси-серверами и, как правило, значительно усложнило бы ментальную модель языка (что уже имеет относительно сложную объектную систему).

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

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

Я имел в виду двигаться вверх, если свойство не было в текущем классе, для поиска общедоступного или защищенного свойства.

Оба упомянутых вами сообщения указывают на проблемы с частным состоянием без подписи. У вас есть идеи по решению этих проблем?

Мне, как человеку, не понимающему внутренней работы JavaScript, очень сложно это сделать.

You'd have to somehow encode a "private key" into each lexical environment.

Я без понятия что это значит. Для чего это? Разве это невозможно сделать?

You'd have to change the semantics of each and every property access (because any property access might result in a private field). Engines are highly optimized around the current property lookup semantics.

Настолько оптимизированы, что одно включение видимости может значительно повлиять на производительность?

Would for-in enumerate over these properties?

Думаю, это будет зависеть от контекста. Да, в одном классе. Однако это не причина не использовать private , это деталь реализации, и другие языки, вероятно, уже ответили на такие вопросы.

Can someone shadow a private property with a normal property lower on the prototype chain? What about the reverse?

Наверное, да (видимость увеличена) на первый вопрос и нет на второй. Опять же, все это было сделано раньше, не так ли?

How do you prevent leaking the names of private fields to clients that shouldn't know that information? This is probably a fatal information leak.

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

All of this runtime stuff is going to be terrible for performance

Используйте «скрытое / безопасное состояние», если хотите perf. : D А если серьезно, о каком типе потери производительности мы говорим? Может, кто-нибудь сможет создать прототип. знак равно

Also, we couldn't use such a solution to self-host the built-ins

Разве встроенные модули самостоятельного хостинга (если я даже понимаю, что это значит) не будут действительно плохими для производительности? Если нет ... используйте «скрытое / безопасное состояние», а не частную / защищенную видимость более высокого уровня.

Я думаю, что усложнение поисковой цепочки было бы рискованным с точки зрения совместимости

Я не первый / единственный человек, который думает, что это может / может работать именно так. Вы обращаетесь к свойству, оно обращается к дескриптору на предмет видимости и соответствующим образом реагирует. Это не кажется сложным, если вы не знаете, как на самом деле все работает в JS. Мне действительно нужно прочитать ускоренный курс по внутренним алгоритмам JS / поиску свойств. = P

Я думаю, что Ruby - хороший пример частного состояния с сигиллой - @

Ruby даже не является языком C-семейства, и, похоже, здесь нет общедоступных полей, а есть только геттеры и сеттеры (аксессоры). В текущем предложении частного состояния есть несколько объявлений, расположенных бок о бок, с одной и той же общей целью (объявление свойств), но явно разных и непоследовательных синтаксисов.

С учетом всего вышесказанного, я не в себе, и я, скорее всего, добавляю больше шума, чем ценности, поэтому я постараюсь промолчать и позволить экспертам прийти к консенсусу.

Я обсудю это желание с TC39, и мы посмотрим, сможем ли мы придумать какие-либо другие идеи о том, как избежать префикса. Лично у меня их нет. Обратите внимание, что если TypeScript все же решит реализовать частные поля, они все еще находятся на этапе 1 в TC39 и, следовательно, могут быть изменены.

Что команда TypeScript думает о синтаксисе и использовании префикса символа / символа?

Я лично считаю, что это выглядит ужасно ...

Примечание. Я предложил избавиться от ужасного синтаксиса # .

@ shelby3 К сожалению, я не считаю это реальным вариантом. tl; dr, нам нужно беспокоиться о том, как все будет взаимодействовать с eval ; отсутствие сигилы просто делает все «слишком динамичным» для правильной работы.

@littledan Я следил за этим сейчас и свой самый сильный аргумент против использования сигилы и мой аргумент в пользу максимальной совместимости с TypeScript . Теперь я понимаю, почему мы должны декларировать конфиденциальность нетипизированных аргументов методов.

@isiahmeadows

По большей части он заменит текущую псевдоприватную реализацию [...] Кроме того, наиболее важной частью предложения является то, что частные свойства доступны только внутри самого класса.

Надеюсь, это не заменит псевдоприватную реализацию. Я думаю, что доступность только внутри класса на самом деле не такая уж и хорошая вещь (учитывая, что под доступностью вы подразумеваете доступность ). Я допускаю, что могут быть особые ситуации, когда имеет смысл иметь строго закрытые и недоступные свойства, например, в целях безопасности. Я также признаю, что людей, знакомых с другими языками, явно сбивает с толку тот факт, что private на самом деле не так уж и частен в JavaScript. Но помимо соображений безопасности, на мой взгляд, большинству разработчиков следует использовать private большую часть времени только для определения контракта, но не для управления доступом.

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

• что он позволяет выразить контракт интерфейса типа и то, как он предназначен для использования клиентами
• что контракт проверяется во время компиляции компилятором TS
• что я все еще могу сознательно «нарушать» контракт во время выполнения, особенно для модульных тестов белого ящика.

Доступность частных свойств во время выполнения в значительной степени способствует тестируемости, потому что я могу ввести частное состояние в тестируемый класс, просто установив его частные поля (в TypeScript я рекомендую использовать скобки вместо приведений any из-за лучшего поддержка рефакторинга), например:

let instance: ClassUnderTest = new ClassUnderTest();
instance["_privateField"] = "My injected state";

Нет необходимости в сложном тестовом коде, просто чтобы настроить класс с определенным (частным) состоянием.
Еще одно преимущество псевдоприватных свойств состоит в том, что они необходимы для исправления обезьян .

@ about-code См. https://github.com/tc39/proposal-private-fields/issues/33

Я не думаю, что сообщество TypeScript с радостью изменило бы все свои строки private variable на private #variable .

С точки зрения TypeScript, большинство из нас довольны своими прекрасными иллюзиями хорошего языка (intellisense, ошибки времени сборки, типы, различные сахара). Эти иллюзии дают нам лучший опыт разработки, мы быстрее пишем лучший код. Это основная причина, по которой мы используем TS помимо транспиляции ESNext - но для последнего есть Babel, и это лучше (или, по крайней мере, было лучше, когда я последний раз проверял).

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

Но в остальном нам: нам действительно не нужен частный JS. Нам нужны простые и легкие переменные private convenient точно так же, как мы использовали их в C ++, Java, C # и т. Д.

Пожалуйста, проголосуйте за решение, которое не доставит нам боли. Может быть, софт приват? Потому что я сомневаюсь, что нам нужен личный знак #variable . Или, может быть, TS private и ES private будут разными концепциями? Уродливый.

@igabesz

Я не думаю, что сообщество TypeScript с радостью изменило бы все свои строки private variable на private #variable

Собственно, с этим предложением private не понадобятся. Вместо этого знак # заменяет его полностью без конфликтов.

Но в остальном нам: нам действительно не нужен частный JS. Нам нужны простые и удобные частные переменные, такие же, как мы использовали их в C ++, Java, C # и т. Д.

Частный тип TypeScript является мягким частным, как и в большинстве объектно-ориентированных языков. Даже частные переменные Java все еще технически являются soft-private, потому что они по-прежнему доступны с помощью аварийного выхода. JS private эквивалентен использованию закрытия, за исключением того, что вы все еще можете получить доступ к частному состоянию экземпляров, отличных от this .

Пожалуйста, проголосуйте за решение, которое не доставит нам боли. Может быть, софт приват? Потому что я сомневаюсь, что нам нужна личная # переменная сигилы. Или, может быть, TS private и ES private будут разными концепциями? Уродливый.

Это были бы разные концепции, но в целом аварийные люки редко используются на практике. Основное исключение - проверка объектов (например, инструменты разработчика, Node.js util.inspect ), но большинство из них определяются хостом и уже используют привилегированные собственные API-интерфейсы, поэтому нет необходимости добавлять его в спецификацию.

Кроме того, как только ES стандартизирует частное состояние, TS примет его и, вероятно, откажется от своего собственного механизма soft-private, который будет удален в следующей основной версии. Он всегда был строгим надмножеством ES, и в него были добавлены (асинхронные функции), изменены (классы) и / или устаревшие ( /// <amd-dependency /> ) функции, необходимые по мере развития самого ES, чтобы поддерживать себя как строгие надмножество и не дублировать текущую спецификацию.

Кроме того, как только ES стандартизирует частное состояние, TS примет его и, вероятно, откажется от своего собственного механизма soft-private, который будет удален в следующей основной версии.

😭

Кроме того, как только ES стандартизирует частное состояние, TS примет его и, вероятно, откажется от своего собственного механизма soft-private, который будет удален в следующей основной версии.

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

@mhegazy Хорошо. Я исправился. (Кстати, это была обоснованная догадка.)

Предложение Class Fields сейчас находится на этапе 2, поэтому я рад, что команда TypeScript продумала это и готова следовать стандартам EcmaScript 💯

Если и когда предложение частного государства достигнет правильного состояния, TS реализует его.

@mhegazy Стадия 3 -

РЕДАКТИРОВАТЬ: возможно, я нашел свой ответ 😄

@styfle см. обсуждение из заметок о совещании по проектированию (# 16415), в котором обсуждаются текущие соображения по поводу реализации.

Подходит ли этап 3 для реализации?

да. Мы начинаем изучать различные варианты исполнения этой функции.

Предложение по классам сейчас находится на этапе 3. (По состоянию на месяц назад)

Предложение по классам сейчас находится на этапе 3. (По состоянию на месяц назад)

В то время как поля класса достигли стадии 3, частные методы и средства доступа последовали за этим и были на стадии 2 до вчерашнего дня, когда она была перемещена на стадию 3. Теперь все необходимое для обращения к частным членам классов находится на стадии 3.

Есть ли новости о позиции / прогрессе команды TS по внедрению синтаксиса #[field] сейчас, когда он уже некоторое время находится на этапе 3? Лично мне это очень не нравится, и я предпочитаю существующее ключевое слово TS private , но в то же время хочу быть максимально приближенным к стандартам.

Лично мне это очень не нравится, и я предпочитаю существующее частное ключевое слово TS

я тоже это так уродливо

но @mhegazy я бы хотел (попробовать) сделать это, можно?

Синтаксический анализ не должен быть плохим (почти новый модификатор, который, по сути, просто токен), но проверка типов будет затруднительной (поскольку у нас будет два разных типа частных, которые нужно будет как-то сравнить), и emit на @rbuckton есть идеи по этому частные статики (и, возможно, декораторы ) (с учетом того, как все они взаимодействуют, может быть лучше добавить их все сразу).

Достаточно сказать, что здесь много всего.

@weswigham Хорошо, я сдаюсь 😂

Предупреждаю, что я (с

Обновление: наша работа находится здесь .

да. Мы начинаем изучать различные варианты исполнения этой функции.

Мне тоже не нравится синтаксис # , но я понимаю технические причины этого синтаксиса. @mhegazy Что я действительно хотел бы сделать от команды TypeScript после реализации нового предложения, чтобы подумать, что TypeScript будет делать с устаревшими реализациями, такими как namespace , private которые можно использовать, но обычно следует нет, поскольку есть лучший способ сделать то же самое или почти то же самое.

Я также хочу добавить свои несколько центов около protected . Если (теперь надеюсь) мы собираемся когда-нибудь удалить / упразднить ключевое слово private я думаю, что можно сделать то же самое с ключевым словом protected . Я знаю, что большинство людей могут не согласиться, но да, дополнительные области видимости иногда могут быть полезны, но общая ценность этого невысока, imho.

@pleerock ,

Вот что я ожидал увидеть от TypeScript:

class Example {
    private a = 1;
    #b = 2;
}

Emit (нацеливание на ESNext):

class Example {
    a = 1;
    #b = 2;
}

Emit (ориентированный на ESNext, с новой опцией компилятора для создания полей, помеченных как частные как закрытые поля ES):

class Example {
    #a = 1;
    #b = 2;
}

Это должно быть обратно совместимо, а также позволять использовать частные поля ES с чистым синтаксисом.

@ glen-84, конечно, будет, я говорил о долгосрочном плане по устаревшим ключевым словам и синтаксисам

Мы не планируем отказываться от какого-либо синтаксиса или ключевых слов.

Я также не думаю, что у нас будет какой-либо вариант для преобразования private в # - у них другое ожидаемое поведение; # - это жесткая конфиденциальность во время выполнения, а private - это просто конфиденциальность во время разработки.

@weswigham, я @RyanCavanaugh да, это был ожидаемый ответ. Но все же я бы применил хотя бы некоторую стратегию для новых пользователей, чтобы избежать использования пространств имен / частных ключевых слов, потому что имхо они устарели с последними предложениями ecmascript

Люди обычно понимают это на основе чтения документации, которую мы, конечно же, обновляем. module foo { все еще присутствует в языке, но в основном больше не встречается в дикой природе, за исключением очень старых кодовых баз, предшествующих namespace foo { .

@RyanCavanaugh рад это слышать. Но все же я верю, что новые люди, пришедшие из C #, скажем, обязательно попытаются использовать пространства имен (не все, но некоторые из них). Я предполагаю, что то же самое может быть с пользователями, пришедшими с других языков - они начнут использовать частные вместо # и это, как правило, более масштабно, чем пример с пространствами имен

Я также не думаю, что у нас будет какая-либо возможность перенести частное в # - у них другое ожидаемое поведение; # - это жесткая конфиденциальность во время выполнения, а private - только конфиденциальность во время разработки.

Ооо. Я надеялся, что мы можем дополнительно использовать private для жесткой конфиденциальности, чтобы избежать ... неудачного синтаксиса.

В любом случае, soft-private, вероятно, достаточно для моих (текущих) случаев использования.

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

РЕДАКТИРОВАТЬ: черт побери, забыл, что версия 3 уже выпущена.

Просто к вашему сведению, в репозитории предложения TC39 есть недавний отток по поводу частных полей / слотов / чего угодно, так что даже нельзя быть уверенным, что предложение в его текущей форме сделает это. Вот пара актуальных вопросов:

• https://github.com/tc39/proposal-class-fields/issues/100
• https://github.com/tc39/proposal-class-fields/issues/106

Я не TC39, но я лично предлагаю всем сначала подождать, пока синтаксис снова утвердится (возможно, дождитесь этапа 4), а затем реализовать его.

FWIW Я бы не стал интерпретировать обсуждение в tc39 / offer-class-fields # 100 как указание на что-то конкретное. # на первый взгляд выглядит не очень красиво, но предпочтительной синтаксической формы предложено не было, и единственный синтаксис, который, похоже, нужен людям, явно не работает. Должен быть какой-то префиксный сигил, и все попытки разрешить this.someProp быть приватными обречены на провал.

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

Если финал состоит в том, что никто не использует частные поля, если им действительно не нужна жесткая конфиденциальность во время выполнения, это, вероятно, хороший результат для Интернета с точки зрения производительности и возможности отладки.

Я согласен, что это, вероятно, не идеальная проблема, чтобы упоминать, но другая,
tc39 / offer-class-fields # 106, вероятно, гораздо более показателен - там
серьезное обсуждение использования слабых карт, среди прочего, потому что
proxy interop просто отстой.

Исайя Медоуз
[email protected]
www.isiahmeadows.com

В понедельник, 30 июля 2018 г., в 15:38, Райан Кавано [email protected]
написал:

FWIW Я бы не стал интерпретировать обсуждение в
tc39 / поля-предложения-класса # 100
https://github.com/tc39/proposal-class-fields/issues/100 быть
указывает на что-то конкретное. # на первый взгляд не очень красиво, но
не было предложено никакой предпочтительной синтаксической формы, и единственный синтаксис, который
люди, кажется, хотят, явно не работают. Должен быть префикс
какой-то сигил и все попытки разрешить this.someProp быть приватным
обречены на провал.

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

Если финал таков, что никто не использует частные поля, если они действительно
требуется жесткая конфиденциальность во время выполнения, это, вероятно, хороший результат для Интернета в
с точки зрения производительности и отлаживаемости.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/Microsoft/TypeScript/issues/9950#issuecomment-408984395 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AERrBGCphyQUu5lJQW7lgsqALLL3e0_Wks5uL2DLgaJpZM4JVDwV
.

Есть некоторое обсуждение использования WeakMaps, но я не вижу, как это могло бы улучшить взаимодействие с Proxy. Я бы пригласил любого члена TC39, у которого есть другое представление о том, как должны работать функции частного класса, представить его комитету для обратной связи; в настоящее время это предложение находится на этапе 3 и теоретически представляет собой консенсусную позицию комитета. Многие люди пошли на компромисс, чтобы достичь общей цели, включив эту функцию, даже когда возможны другие конструкции.

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

@RyanCavanaugh

FWIW Я бы не стал интерпретировать обсуждение в tc39 / offer-class-fields # 100 как указание на что-то конкретное. # на первый взгляд выглядит не очень красиво, но предпочтительной синтаксической формы предложено не было, и единственный синтаксис, который, похоже, нужен людям, явно не работает. Должен быть какой-то префиксный сигил, и все попытки разрешить this.someProp быть приватными обречены на провал.

Поздно, но на самом деле есть предложение, предлагающее синтаксис this->var .

Конечно, это предложение, скорее всего, мертво («комитет не был в восторге» - единственная причина, по которой мне удалось найти). Но действительно был предложен альтернативный синтаксис, и я надеюсь, что все заинтересованные стороны знакомы и осведомлены о нем.

Я думаю, было бы неплохо иметь возможность компилятора сделать private transpile в какой-то _soft_ private, который будет применяться во время выполнения. Я не думаю, что вариант использования, требующий истинной жесткой приватности, особенно распространен, поэтому, даже если не считать какой-либо неприязни к синтаксису # , я думаю, что большинство людей будут склонны придерживаться private . Но частный только во время компиляции - это слишком мягкий IMO. Кроме того, такой вариант поможет уменьшить количество возможных вариантов приватного ... если разработчикам останется реализовать это самостоятельно, тогда у вас может быть все это:

class Demo {
  private a

  #b

  <strong i="9">@reflect</strong>
  #c
}

Поэтому я предлагаю, чтобы с включенной новой опцией private a трансформировалось в <strong i="13">@reflect</strong> #a , где @reflect - это декоратор, который позволяет отражать свойство через API, поддерживаемый сообществом. Были некоторые разговоры о стандартной библиотеке декораторов, поэтому декоратор @reflect (или как бы мы его ни называли) может быть стандартизирован в будущем; Я думаю, это был бы хороший кандидат для этого.

Я полагаю, что основным недостатком моего предложения будет влияние на производительность. Мы можем надеяться, что однажды в JS могут появиться некоторые стандартные декораторы, которые будут реализованы изначально для их оптимизации, но реальность в обозримом будущем такова, что <strong i="19">@reflect</strong> #x будет медленнее, чем просто #x . Но я предлагаю это только как вариант, который, вероятно, должен быть отключен по умолчанию (в том числе по причинам обратной совместимости).

@MichaelTheriot

Поздно, но на самом деле есть предложение, предлагающее синтаксис this-> var.

Конечно, это предложение, скорее всего, мертво ("комитет не был в восторге" - единственная причина, по которой мне удалось найти)

Комитет привел множество хорошо продуманных причин для одобрения текущего предложения вместо предложения классов 1.1, например https://github.com/tc39/proposal-class-fields/issues/100#issuecomment -429460917

@mbrowne

Возможно, я это пропустил. Страница проблем классов 1.1 была неактивна в течение полугода, и даже пример, который вы указали, был написан через месяц после моего комментария.

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

Изменить: мой комментарий не предполагает, что TypeScript делает что-то другое. Я считаю полезным исправить дезинформацию по упомянутым вопросам предложения.

@MichaelTheriot стороны, которые должны быть проинформированы об альтернативных предложениях, не являются сторонами, участвующими в этом разговоре. TypeScript будет следовать предложению, которое должно быть ратифицировано. Тот факт, что альтернативные синтаксисы были предложены, но не приняты, на мой взгляд, не очень полезен для этого разговора.

Привет, ребята, если это поможет, я хотел бы поделиться своей собственной реализацией защищенных / закрытых членов среды выполнения:

См. lowclass .

Ознакомьтесь с обширными тестовыми файлами, показывающими все виды использования открытых / защищенных / закрытых членов среды выполнения. Реализация недолговечна, и некоторые функции могут быть опущены, чтобы иметь только минимальную защищенную / частную функциональность.

Примечания:

• Он использует WeakMaps для хранения защищенного / частного состояния.
• В отличие от других реализаций, которые я видел, он работает с асинхронным кодом с обратными вызовами / обещаниями / ожиданием, потому что он не полагается на синхронную трассировку стека вызовов.
• Он работает с геттерами / сеттерами (включая супервызовы) (см. Тесты).
• Работает с родным super или с помощью помощника Super для ES5 (см. Тесты).
• Поддерживает метод constructor (см. Тесты).
• Возможность расширения встроенных классов (кроме Date, но я хотел изучить это, хотя люди говорят, что это невозможно, но я хочу это подтвердить. См. Тесты, например, работа с собственными пользовательскими элементами).
• Возможность расширения обычных родных class es (см. Тесты).
• оберните родные class es, предоставив им защищенные и частные возможности (см. тесты).
• Напишите классы function стиле ES5 вместо собственных class es (см. Тесты).
• много места для оптимизации производительности (например, кэширование супер / защищенных / частных вызовов помощников и оптимизация алгоритмов поиска)

Чтобы запустить тесты:

npm install
npm test

Также см. Https://github.com/babel/proposals/issues/12 и https://github.com/babel/babel/issues/8421 для получения подробной информации и проблем с реализацией Babel.

Всем привет,

пожалуйста, не реализуйте еще не завершенную спецификацию полей частного класса. Есть проблемы.

Пожалуйста, прочтите эту ветку .

Я бы посоветовал всем, кто это читает, взглянуть на некоторые другие идеи синтаксиса (просто просмотрите, есть еще кое-что) и высказать свое мнение.

например, вот еще один поток (с лучшими идеями синтаксиса, чем текущий # IMHO).

Если какое-либо сообщество JavaScript уже широко использует общедоступный / частный / защищенный, то это сообщество TypeScript, которое имеет большой шанс помочь сформировать будущее частного / защищенного JS.

Итак, поля частного класса поставляются в V8 v7.2 и Chrome 72. Есть ли какие-либо планы начать реализацию предложения частных полей?

@ ChrisBrownie55 Публичные поля отправляются. Частными нет.

@jhpratt , это плохо, но похоже, что команда Chrome планирует в ближайшем будущем поставить частные версии.

Для справки: https://v8.dev/blog/v8-release-72#public -class-fields

В нем документируется, что они отправляют поля общедоступных классов, начиная с версии V8 7.2, но есть кое-что, касающееся частных полей (выделено мной):

Поддержка полей частных классов запланирована в будущем выпуске V8 .

@isiahmeadows На самом деле я имел в виду другую публикацию в блоге разработчиков Google.

Заключение

Поля общедоступных классов поставляются в V8 v7.2 и Chrome 72. В ближайшее время мы планируем выпустить поля частных классов.

Ссылка на статью в блоге разработчиков Google

Эти статьи были написаны @mathiasbynens и Андреасом Хаасом, у которого вы можете попросить разъяснений при необходимости (хотя я думаю, что каждый из этих постов был довольно ясным). cc @gsathya и @joyeecheung , которые работают над завершающей работой над реализацией V8.

Так или иначе, встреча TC39 в январе 2019 года завершила полтора года переосмысления альтернатив предложениям о частных областях и методах еще одним подтверждением консенсуса по предложениям. Я думаю, мы можем считать текущую версию стабильной и готовой к переходу на TypeScript.

Chrome только что выпустил поля частного класса 🎉
Они есть только в Chrome 74, выпущенном в настоящее время в сборке _canary_.

Я только что отправил поля частного класса в Chrome 74! Попробуйте это в Chrome Canary уже сегодня!
- Сатья Гунасекаран через Twtiter

Кто-нибудь знает, где мы находимся, выбирая конкретную реализацию (или создавая ее) для полей частного класса? Я видел, что @trusktr рекомендовал lowclass, но я не знаю, является ли "_Private Inheritance_" частью спецификации.

Это определенно не так; частные поля не проходят по цепочке прототипов (потому что тогда другие объекты смогут их видеть, и, следовательно, они не будут частными)

Я предполагаю, что частные поля будут перенесены в WeakMaps (по одной WeakMap на поле, точно так же, как это делает Babel). Также должна быть возможность сохранить синтаксис # в окончательном выводе для тех, кто ориентирован исключительно на браузеры, которые его поддерживают (конечно, со временем это станет более актуальным).

По соображениям производительности, возможно, стоит рассмотреть вариант, который позволил бы разработчикам использовать синтаксис # для будущей совместимости (когда его поддерживают больше браузеров), но фактически переносить в общедоступные свойства с некоторым специальным префиксом, например __ts# . WeakMaps следует протестировать, чтобы увидеть, действительно ли это необходимо, но я подозреваю, что разница в производительности между общедоступными свойствами и WeakMaps может быть значительной. Если такая опция была добавлена, она, конечно, должна быть отключена по умолчанию, поскольку разработчики, использующие синтаксис # , обычно ожидают, что она будет закрытой как во время компиляции, так и во время выполнения. Но для тех, кто хочет максимизировать производительность во время выполнения и доволен тем, что пока что используется только конфиденциальность во время компиляции, это может быть хорошим способом начать использовать новый синтаксис, не вызывая потенциально ухудшения производительности.

Есть новости о ходе реализации? Может быть, PR, который мы можем создать для тестирования и предоставления обратной связи?

@jhpratt конечно! Если вы проверите ветку в этом PR , вы сможете протестировать поля экземпляра с частным именем. Методы и средства доступа находятся в разработке.

Мы надеемся продолжить эту работу. Мы можем PR изменений в этом репо (Microsoft / TypeScript), как только это предварительное требование PR будет объединено: https://github.com/Microsoft/TypeScript/pull/30467.

Отзывы приветствуются.

Я не знаю, является ли "Частное наследование" частью спецификации.

Замечание, я планирую отказаться от этой функции в lowclass, чтобы обеспечить 100% истинную конфиденциальность. На практике мне это действительно не понадобилось, это был скорее эксперимент.

Между прочим, я чувствую себя здесь, на случай, если какая-либо теория о «частном наследовании» может оказаться полезной (может быть, просто интересной или, возможно, поможет зажечь какие-либо другие идеи):

«Частное наследование» (как показано в текущей версии lowclass) означает, что подкласс может использовать частные методы, унаследованные от суперкласса, но метод применяет изменения _ только _ к частным свойствам экземпляра _ в рамках этого подкласса_, как если бы у подкласса эти методы были определены как частные в его собственном определении, но подкласс не может изменять частные свойства экземпляра в области суперкласса или класса-брата.

Для сравнения, в «защищенном наследовании» подкласс _ может_ изменять свойства своего собственного экземпляра или экземпляра суперкласса, но по-прежнему не может изменять свойства родственного класса. В защищенном наследовании подкласс изменяет свойства, которые могут видеть все суперклассы (все суперклассы читают / записывают те же свойства).

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

Не уверен, что это имело смысл, поэтому вот простые примеры кода, объясняющие, на что было бы похоже «частное наследование», если бы мы написали его, используя текущие функции частных полей предложений-классов-полей ecma:

В полях класса-предложения нет "частного наследования", поэтому следующее не будет работать (и я согласен, что это желательно для сохранения истинной конфиденциальности):

class Foo {
    test() {
        this.#privateMethod()
    }

    #foo = 'foo'

    #privateMethod() {
        console.log(this.#foo)
    }
}

class Bar extends Foo {
    test() {
        // This does not work, no private inheritance:
        this.#privateMethod()
    }

    // #foo is private only inside Bar code, it is NOT the same #foo as in Foo
    // scope.
    #foo = 'bar'
}

В lowclass «частное наследование» было бы эквивалентно написанию следующего не-DRY кода для имитации того же самого с использованием некоторого копирования / вставки в вашем редакторе:

class Foo {
    test() {
        this.#privateMethod()
    }

    #foo = 'foo'

    #privateMethod() {
        console.log(this.#foo)
    }
}

class Bar extends Foo {
    test() {
        // This does not work, no private inheritance:
        this.#privateMethod()
    }

    // #foo is private only inside Bar code, it is NOT the same #foo as in Foo
    // scope.
    #foo = 'bar'

    // copy the method over by hand (because there's no private inheritance):
    #privateMethod() {
        console.log(this.#foo)
    }
}

В обоих примерах переменная #foo является отдельной переменной для каждого класса. Переменных #foo две, а не одна; каждый из них доступен для чтения и записи только кодом в одном определении класса.

В низком классе частное наследование позволяет нам повторно использовать частные методы суперкласса, _ но_ метод работает в той области, в которой он используется. В итоге получается, что мы скопировали и вставили метод суперкласса в подкласс, как в приведенном выше примере, но по-прежнему существуют две отдельные переменные #foo для каждого класса.

В низком классе, если #someMethod используется в суперклассе, он работает с #foo суперкласса. Если #someMethod используется в области действия подкласса, он работает с #foo подкласса, а не с #foo суперкласса!

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

Теперь он находится в стабильном канале Chrome, поэтому разработчики могут использовать его изначально. Меня больше всего интересует эта проблема из-за VSCode - при написании vanilla .js javascript VSCode отмечает это как ошибку. Есть ли способ добавить поддержку полей частного класса в Vanilla JS в VSCode отдельно от дискуссии о том, добавлять ли их в Typescript?

Лично я не считаю, что TS должен добавлять для них поддержку до того, как он достигнет стадии 4. У TS уже есть приватное время компиляции, которое на данный момент работает достаточно хорошо. После того, как он достигнет стадии 4, я согласен, что это имеет смысл. (В обсуждении также случались эпизодические приступы нестабильности, поэтому я все равно не считаю, что это готово для прайм-тайма.)

Обновление: он также поддерживается в стабильной версии Node 12. Также в Babel есть плагин для преобразования этого синтаксиса. Разработчики часто используют функции до того, как они станут предложениями стадии 4. Я хотел бы видеть добавленную поддержку этого синтаксиса в Vanilla JS (не ts) или способ включить его через jsconfig.json чтобы VSCode не отображал ошибку при их использовании. В репозитории VSCode говорится, что их поддержка JS поддерживается TypeScript, и упоминается об этой проблеме.

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

Я бы предложил, чтобы TypeScript вводил частные поля под флагом, который указывает, что эта функция является экспериментальной и может быть изменена между этапом 3 и этапом 4.

Может быть, мы могли бы сначала реализовать поддержку синтаксиса без семантики?

Может быть, мы могли бы сначала реализовать поддержку синтаксиса без семантики?

Для проверки типов / intellisense, я думаю, должна быть какая-то семантика, но не может быть поддержки преобразования нижнего уровня, такой как BigInt (может использоваться только с esnext ).

fwiw, это может быть изменено только на этапе 3 из-за обратной связи с реализацией. Учитывая, что поставляется хром, любые изменения маловероятны.

@ ChrisBrownie55 Я бы сказал, что нет никакого смысла в том, что эта функция еще не реализована

Похоже, это в процессе:
https://github.com/microsoft/TypeScript/pull/30829
(который, по-видимому, ждет https://github.com/microsoft/TypeScript/pull/30467)

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

Ребята, просто потому, что крупный браузер реализовал эту функцию (посмотреть, как она себя чувствует, поиграть с ней и т. Д.), Не означает, что все должны это делать.

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

Как упоминал @isiahmeadows , предложение о полях классов вызывает споры, и многим оно не нравится. Вот пара проблем, показывающих неприязнь сообщества к текущим частным полям:

• https://github.com/tc39/proposal-class-fields/issues/100
• https://github.com/tc39/proposal-class-fields/issues/150

Если бы я был разработчиком языка, меня бы это беспокоило, и я не хотел бы нести ответственность за выпуск столь нелюбимой функции (высеченной в камне), потому что я решил позволить тысячам (не знающих) разработчиков начать использовать проблематичную особенность в производственном коде.

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

@trusktr Это может быть спорная функция, но вопрос о том, будут ли ее использовать разработчики, должен решать разработчик, а не инструменты. Крупный браузер поставляет его не для того, чтобы «поиграть с ним», а для использования в производственной среде. Он также поставляется в Node, самой популярной серверной среде выполнения JS. Опять же, меня меньше беспокоит, соответствует ли синтаксис TypeScript или нет, но больше беспокоит, поддерживается ли синтаксис языковым сервером JavaScript в VSCode (который поддерживается TypeScript).

Он также поставляется в Node

Только как побочный эффект выпуска Chrome, который поддерживает движок Node JS.

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

Это может относиться к таким разработчикам, как вы (возможно, вам просто нужно выпустить продукт, и вы будете работать с любыми имеющимися у вас инструментами, что, собственно, и нужно делать в этом отношении, и то, что делают многие нанятые разработчики).

Есть также много разработчиков, которые могут не знать о ножных пушках, связанных с полями классов, просто пытаясь использовать данные им инструменты.

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

Хорошо то, что в новых закрытых полях используется синтаксис # , все еще есть место, чтобы исправить это, используя ключевое слово private в качестве альтернативы.

Действительно ли TS должен на 100% следовать стандарту? Мы уже знаем, что комитет идет против сообщества с thisGlobal или #privateLol , так что, может быть, пора сказать, что Google не имеет монополии на JavaScript, пока не стало слишком поздно?

@TeoTN Частные поля не принадлежат Google. Он прошел через TC39, как и любой другой недавний стандарт.

Несколько моментов, которые помогут внести ясность:

• Мы не торопимся поставлять функции ES, которые еще не полностью реализованы (см. Также: необязательное связывание, объединение с нулевым значением, выражения throw, оператор конвейера, nameof и т. Д.)
• И наоборот, реализация утвержденных и отправляемых функций ES не является обязательной.
• Многие люди, которым не нравятся определенные вещи, в любом случае не имеют значения.
• Частные поля будут в TS, если мы сочтем, что их можно безопасно реализовать без последующих изменений дизайна (или отзывов), вызывающих серьезные неудобства для пользователя.

@RyanCavanaugh Спасибо за разъяснения, а также за

Можно с полным основанием сказать, что приватные поля полностью запечены.

@kkimdev Стадия 4

Функции ES, которые не полностью реализованы

Любопытно, что такое полностью запеченные функции ES? Что означает «полностью запеченный» в этом примере?

реализация ратифицированных и отправляемых функций ES не является обязательной

Это вполне разумно, если учесть, что цель TypeScript состоит в том, чтобы просто вводить типы вместо ванильного JS (поэтому такие вещи, как namespace были плохим выбором с точки зрения текущих целей, а enum тоже спорно).

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

Кажется неэффективным, поскольку члены команды TS сидят на TC39, поэтому они уже были частью консенсуса в отношении функции, находящейся на этапе 3, прежде чем кто-либо отправил ее в первую очередь, включая эту.

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

Я думаю, что лучшее место для обсуждения этих языковых дизайнерских решений было бы в репозиториях предложений, на собраниях TC39 и в других контекстах, посвященных этой работе. Мы подробно обсудили предложения по приватным полям и методам с @trusktr ; обсуждение здесь кажется не по теме.

В конечном счете, я думаю, что TC39 - это то место, где мы должны продолжить разработку языка, а репозиторий TypeScript мог бы быть местом для обсуждения других аспектов, таких как приоритет и детали реализации для функции, а также суждение о том, когда функция Достаточно стабильный для отправки.

Поскольку TypeScript Intellisense обеспечивает подсветку синтаксиса JavaScript в VS Code и две проблемы с подсветкой синтаксиса, которые я обнаружил (Microsoft / vscode # 72867 и Microsoft / vscode # 39703) в перенаправлении репозитория VS Code, здесь - где обсуждается реализация этого в TypeScript - позвольте мне внести свой вклад, сказав, что было бы здорово, если бы это не было ошибкой в ​​файлах JavaScript.

Совершенно корректный JavaScript помечается как ошибочный в VS Code, потому что компилятор для другого языка находится в процессе принятия решения о том, будет ли синтаксис поддерживаться или нет. :-)

У меня нет проблем с TypeScript, который не торопится, прежде чем принять решение по этому поводу (на самом деле я поддерживаю его!), Но это влияет на подсветку синтаксиса JavaScript таким образом, который не может быть легко исправлен или работоспособен даже локально (насколько это возможно). Я знаю), исправив файл грамматики подсветчика синтаксиса, потому что исправлять нечего (AFAIK).

Хотя я не являюсь членом команды TypeScript, они активно работают над реализацией этого, и я не думаю, что на данный момент есть много сомнений в том, что частные поля будут поддерживаться. См. Https://github.com/microsoft/TypeScript/pull/30829.

Я могу подтвердить, что над этим работают - мы сотрудничаем с командой TS и в настоящее время завершаем перебазирование. В восторге от полей с частными именами в TS (и, соответственно, Language Server).

Большое спасибо нашим сотрудникам из Bloomberg за реализацию этого в https://github.com/microsoft/TypeScript/pull/30829!

Привет. Если вы хотите, чтобы я создал для этого отдельный выпуск, сообщите об этом. Мне интересно узнать, каково обоснование выдачи специального сообщения #private PropertyDeclaration которое привело к этой проблеме .

Например, будут сгенерированы следующие объявления:

// index.d.ts
declare class Foo {
    #private;
    // ...
}

... Учитывая ввод:

// index.ts
class Foo {
    #name: string;
}

Сначала я пытаюсь понять, почему он должен быть там, но также можно ли его не учитывать, учитывая, что я создаю инструменты для генерации объявлений.

Сначала я пытаюсь понять, почему он должен быть там, но также можно ли его не учитывать, учитывая, что я создаю инструменты для генерации объявлений.

Наличие частного делает класс номинальным в нашем анализе, поэтому важно сохранить его в файле объявлений. Возможно, вы могли бы использовать инструмент преобразования объявлений после отправки, например dts-downlevel чтобы каким-то образом понизить уровень частного объявления для старых TS? (Я не знаю, есть ли у него нижний уровень для #privates)

В дополнение к сказанному Уэсли: downlevel-dts преобразует #private в модификатор private для совместимости со старыми версиями TypeScript.

Наличие частного делает класс номинальным в нашем анализе, поэтому важно сохранить его в файле объявлений.

Не могли бы вы рассказать, как это делает класс номинальным? 🙂 Учитывая несколько частных свойств, #foo и #bar , к объявлениям будет добавлено только одно специальное объявление #private ambient. Невозможно проанализировать из объявлений ни имена частных свойств, ни их количество, потому что все они заменяются одним объявлением свойства #private . Я бы лучше понял, если бы он сохранил имена #foo и #bar . Это немного странно, особенно учитывая, что LanguageService жалуется, что свойство #private никогда не используется. Мне это кажется ошибкой. Но при любых обстоятельствах частные поля не являются частью общедоступных свойств типа и недоступны извне класса, поэтому теоретически я не понимаю, почему они должны быть частью объявлений? Разве не должны применяться те же принципы, что и для полей и методов, аннотированных другими модификаторами доступа, кроме public в которых они не являются типом KeyOf и не являются частью внешних объявлений?

Чтобы добавить к сказанному Уэсли: downlevel-dts преобразует #private в модификатор private для совместимости со старыми версиями TypeScript.

Похоже на прекрасное решение. Однако при этом любое свойство, которое вы даете модификатору private , не будет частью файла .d.ts поскольку оно не является частью общедоступных свойств типа. Меня особенно интересуют объявления, которые даже с простейшими примерами генерируют диагностику неиспользуемого свойства с именем #private .

@wessberg Я сообщил об ошибке, которую вы заметили в предупреждениях о нежелательных языковых службах, и, вероятно, смогу реализовать решение.

Повторите свой другой вопрос:

Не могли бы вы рассказать, как это делает класс номинальным?

Кто-то уже поднимал вопрос об этом раньше .

Одна из причин сделать что-то номинальное в этих случаях заключается в том, чтобы разработчик класса мог поддерживать некоторый скрытый инвариант среди частных полей: создание структурных типов подорвало бы эту цель, по крайней мере, без действительно причудливых типов, которые могут выражать такие вещи, как «список всегда сортируется "или" диаметр равен 2 * радиусу ".

Другая причина заключается в том, что код, подобный приведенному ниже, не должен проходить проверку типа, поскольку он не может «делать правильные вещи» во время выполнения:

class A {
    #foo = getFoo();
    bar = "bar";
    equals(other: A) {
        return this.#foo === other.#foo && this.bar === other.bar;
    }
}

new A().equals({ bar: "bar" }); // error: missing property '#foo'

Привет, ребята, я так рад, что у нас есть синтаксис #private ! это круто!

но я должен признать, что я действительно расстроен тем, что у нас нет сокращенного синтаксиса (см. предложение) , например:

class Counter {
  #count = 0
  increment() {
    return #count++
  }
}

Мне было интересно - можем ли мы разработать плагин машинописного текста или опцию tsconfig, чтобы включить сокращенный синтаксис в качестве экспериментальной функции?

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

это можно сделать? может быть, есть веская причина, по которой это невозможно? какая будет работа? ваше здоровье!

: wave: chase

@ chase-moskal TypeScript не реализует ничего, кроме типов, выходящих за рамки стандарта ECMAScript. Причина этого в изменении семантики, что демонстрируют частные поля и декораторы.

@ chase-moskal Самый практичный способ избежать постоянного ввода this - это просто назначить для него ярлык в вашей среде IDE (например, F3). Многое можно сделать, создав разветвление парсера TS или Babel и написав плагины, но все они требуют много работы и могут привести к рассинхронизации с официальными инструментами. Я понимаю, что ваш вопрос, конечно, касался официальной поддержки, просто подумал, что поделюсь своими мыслями.

@jhpratt - машинописный текст, который помогает мне оставаться в

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

@mbrowne - на самом деле не удобочитаемость , поэтому давайте не будем беспокоиться о подсчете нажатий клавиш. Я хочу сказать, что повторение javascript this слишком часто является лишним и недостойным беспорядком

теперь подумайте об этом для удобства чтения: когда мы получаем сокращенный синтаксис #private , каждый раз, когда вы когда-либо видите this , вы сразу узнаете, что это было для доступа к общедоступному члену - огромная победа для читаемость!

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

так что все это просто требует больше работы и времени, очевидно, от людей из Bloomberg

без частных методов для сопоставления полей нам просто нужно подождать (потому что никто не будет смешивать приватные машинописные тексты с хэштегами в одном и том же классе, не сойдя с ума!)

Итак, команда Bloomberg модернизирует машинописный текст здесь, и они также участвовали в тех же функциях конфиденциальности для Babel год назад? они делают Божью работу, и мне любопытно, почему! Так держать! ваше здоровье!

: wave: chase

Да, TypeScript дал вам декораторы много лет назад. Угадай, что? Семантика сильно изменилась. Теперь TypeScript застрял в поддержке устаревшего API в ближайшем будущем, и это вызовет массовые поломки, когда его решат удалить. Стрелочные функции являются частью спецификации ECMAScript, поэтому упоминание об этом совершенно неуместно.

TypeScript в настоящее время не реализует никаких предложений ECMAScript до достижения стадии 3. Вот где вам нужно будет получить сокращение, прежде чем TS будет заинтересован.

Да, TypeScript дал вам декораторы много лет назад. Угадай, что? Семантика сильно изменилась.

Мы живем в не идеальном мире, и некоторые функции необходимы прямо сейчас. Например, предложение декораторов все еще находится на стадии 2, но некоторые крупные проекты (Angular) активно их используют уже давно. Другой пример: ECMAScript не указывает модификаторы protected для членов класса, что полезно для решения реальных проблем.

Теперь TypeScript застрял в поддержке устаревшего API в ближайшем будущем, и это вызовет массовые поломки, когда его решат удалить.

Другие языки также вводят экспериментальные функции под флагами компилятора.

Я не говорю, что TypeScript должен реализовывать каждое предложение на этапе 1 или 2, но многие интересные предложения для TS просто застряли, потому что в ECMAScript нет эквивалентов, например https://github.com/microsoft/TypeScript/issues/2000

@ikokostya Я использовал декораторы как пример того, что семантика изменилась после того, как TypeScript реализовал их. Вы действительно говорите, что это сокращение «нужно прямо сейчас»? Поверьте, мы справимся с пятью лишними персонажами. Если для вас это так важно, вы можете создать вилку компилятора.

TypeScript твердо придерживался принципа не реализовывать что-либо до этапа 3, даже под флагом. Это подробно обсуждалось ранее в различных других выпусках.

Я не вижу ничего, кроме хождения по кругу, поэтому не буду отвечать, пока не появится что-нибудь примечательное.

@jhpratt Я не

Предложение о форке абсолютно неуместно.

Не все согласны - и, что более важно, не все в комитете TC39 согласны, - что сокращение сделает код более читаемым или интуитивно понятным. По этому поводу было много дискуссий, и сокращенный синтаксис был вынесен в отдельное предложение из-за этих проблем. (Я недостаточно обдумал это, чтобы сформировать собственное определенное мнение, просто подведу итоги.) Если вы хотите продвигать это предложение, можно продолжить, оставив отзыв в TC39. Я уверен, что уже ведется большая работа по поддержке TS и реализации всех предложений, которые достигли стадии 3, поэтому трудно представить себе, что это будет рассматриваться для TS, если это не продвигается дальше в TC39.

но я должен признать, что я действительно расстроен, что у нас нет сокращенного синтаксиса (см. предложение)

Это сокращение было бы несовместимо с предложением конвейера, в котором также может использоваться # и это уже обсуждалось, чтобы стать предложением этапа 2. На самом деле нет смысла реализовывать предложения так рано, а затем вносить критические изменения. На таком раннем этапе вы даже не знаете, какое предложение выиграет.

Даже если он окажется совместимым, я могу придумать, по крайней мере, еще несколько вариантов использования оператора префикса # которые более полезны, чем сокращение для ввода 5 дополнительных символов.

… Особенно, когда значительная часть варианта использования частных полей вообще не находится в this (например, static isMe(obj) { try { obj.#x; return true; } catch { return false; } } , чтобы назвать один пример).

@phaux - это действительно хорошая информация о сокращении и конвейере, спасибо!

@jhpratt

TypeScript твердо придерживался принципа не реализовывать что-либо до этапа 3, даже под флагом.

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

Я предполагаю (молюсь), что команда Bloomberg продолжает работу Бога над машинописным текстом, как они это делали для Babel год назад? если так, то нам действительно просто нужно набраться терпения и сидеть сложа руки :)

мне действительно кажется, что машинописный текст был намного более конкурентоспособным с babel и браузерами для функций ecmascript, а теперь он на самом деле слишком консервативен - мы находимся в ситуации, когда и babel, и chrome отправляли частные поля (без флагов) в течение года до этого Блумберг пришел, чтобы спасти нас

Меня беспокоит постепенное расхождение между набором функций машинописного текста и babel - мои друзья babel писали красивый и гладкий код в течение последнего года, в то время как я все еще плачу штраф машинописного текста - они смеются надо мной!

Мне понравился этот машинописный текст, который предлагал экспериментальные флаги, которые позволили мне решить, на что я готов рискнуть, рефакторинг в будущем, чтобы купить мне некоторые замечательные функции - это сейчас положение машинописного текста, что слишком опасно позволять разработчикам решать эти риски, и этот машинописный текст теперь моя няня?

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

Мне действительно любопытна динамика здесь - если бы Блумберг не вмешался, как рыцарь в сияющих доспехах, сколько времени прошло бы, прежде чем машинописный текст сам принял бы вызов? или это эксперимент с машинописным текстом: «если мы просто избегаем этих новых функций ... как скоро сообщество просто ... сделает это за нас?», ха, это довольно цинично, даже для меня, задаваться вопросом! или, может быть, это действительно классное доброжелательное сотрудничество, исследующее новые возможности для финансирования и поддержки открытого исходного кода, и оно просто идет немного медленнее, чем ожидалось? или, может быть, философия машинописного текста намного более консервативна, чем раньше? где мы находимся в этом спектре?

для реализации функций этапа 3, что больше из-за того, что машинописному тексту не хватает пропускной способности или приоритета?

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

: wave: chase

Мне понравился этот машинописный текст, который предлагал экспериментальные флаги, которые позволили мне решить, на что я готов рискнуть, рефакторинг в будущем, чтобы купить мне некоторые замечательные функции - это сейчас положение машинописного текста, что слишком опасно позволять разработчикам решать эти риски, и этот машинописный текст теперь моя няня?

Дело не в том, чтобы присматривать за тобой. Речь идет о нежелании тратить время на реализацию функций, которые неизбежно станут бременем обслуживания, когда семантика предложения изменится. Они абсолютно не хотят тратить время на выяснение того, как согласовать измененную семантику, когда они находятся в конфликте с реализацией TS. У них есть дела поважнее. Еще предстоит решить множество проблем, связанных с типами, поэтому имеет смысл потратить на это их ограниченные ресурсы и не пытаться выполнять работу TC39 поверх решения проблем системы типов.

Что касается частных методов и средств доступа: они также не реализованы в V8. Методы класса и поля экземпляра разные, и они не могут просто ... щелкнуть переключателем, чтобы поддержать их тоже. На их внедрение уходит реальное время, и они уже заняты работой, и это небольшая команда. Более того, правило заключается не только в том, что предложение должно быть на стадии 3: они также прямо заявляют, что хотят иметь высокую уверенность в том, что семантика предложения будет окончательной. Хотя это случается редко, семантика _ может_ измениться на этапе 3. Эта функция не реализована в V8 без уважительной причины. Не поймите меня неправильно; Я тоже хотел бы, чтобы это предложение было реализовано, и не могу дождаться, чтобы использовать его. Однако реализация предложений с более ранних этапов - пустая трата времени, и время команде TS лучше потратить в другом месте. Есть бесчисленное количество предложений Этапа 2, 1 и 0, которые я бы _любил_ использовать _today_, но я понимаю, почему я пока не могу их принять. Терпение мой друг.

Вы также вполне можете использовать babel исключительно для транспиляции вашего машинописного текста, если вы предпочитаете варианты, которые предоставляет вам babel.

@ 0kku - значит, вы говорите, что это просто проблема с пропускной способностью / пропускной способностью, а не философская - накопление ошибок теперь имеет более высокий приоритет, чем реализация функций стадии 3, однако, возвращаясь к более ранней истории машинописного текста, возможно, в нем было меньше ошибок , а так проще было выделить мощности под экспериментальные реализации? я могу купить эту теорию, и мы должны подождать или внести свой вклад

@ljharb - о, это очень интересно - действительно ли возможно запустить машинописный текст и babel таким образом? достичь лучшего из обоих миров?

но я просто не могу понять, как языковая служба vscode ts может по-прежнему работать без нарушения незнакомого синтаксиса (например, частных методов)? отсутствие intellisense кусается слишком большой кусок ценностного предложения машинописного текста - если intellisense необходимо полностью отключить, стратегия не работает

как это можно исправить в долгосрочной перспективе? Я полагаю, если бы мы выделили определенные ошибки машинописного текста для синтаксиса каждой экспериментальной функции, а также, если бы проект машинописного текста мог бы отключить эти конкретные ошибки на уровне tsconfig - тогда у нас был бы шанс открыть дверь, чтобы использовать как функции babel, так и функции машинописного текста в то же время - мужик, что было бы реально круто, и выбить весь класс нареканий .. ура!

: wave: chase

@ljharb

Вы также вполне можете использовать babel исключительно для перевода своего машинописного текста.

Я полагаю, вы могли бы настроить процесс проверки типов, в котором вы переносите только частные методы с помощью Babel (но оставляете типы во всем остальном) и выполняете проверку типов в этом коде с помощью tsc . (Сценарий сборки после прохождения проверки типов будет использовать только Babel.) Но вам придется игнорировать множество синтаксических ошибок в вашей IDE - я думаю, что это будет нарушением условий сделки для большинства людей.

@ chase-moskal Хотя то, что сказал @ 0kku, в целом верно, я не видел причин не реализовывать частные методы в TS на данном этапе. Я думаю, что это предложение достигло стадии 3 позже, чем поля классов, и разработчики все еще работают над этим.

Если вам интересно, почему мы не стремимся внедрять экспериментальные функции, пожалуйста, обратите внимание на --useDefineForClassFields . Мы реализовали инициализаторы свойств класса очень, очень рано, исходя из предположения, что никакое возможное предложение TC39 с другой семантикой не может даже существовать правдоподобно, и мы были совершенно неправы.

Декораторы все чаще оказываются в одной лодке, и вас ждет сюрприз, если вы думаете, что мы можем полностью отказаться от поддержки старой семантики. Множество крупных компаний построили вокруг него большие и хорошо принятые структуры; совершенно нереально, что мы могли бы сказать: «Ну, имя флага начинается с experimental поэтому вы должны были знать, что эта функция, поддерживаемая в течение последних 5 лет, может просто сработать и однажды исчезнуть».

Для обеих этих функций мы собираемся застрять, поддерживая здесь два слегка разных кодовых пути до конца нашей жизни, и это отстой, но это компромисс - мы очень привержены сохранению TypeScript от сборки до сборки. обновления возможны без нарушения поведения вашего кода во время выполнения; этот компромисс незаметен, когда он в вашу пользу (например, ваша программа продолжает работать ), но вы можете с большей готовностью увидеть обратную сторону с точки зрения активного принятия функций.

С нашей точки зрения, вы не можете отказаться от совместимости между версиями среды выполнения, так же как вы не можете отказаться от ответственности за халатность.

Мы также воздержались от скорейшего внедрения необязательной цепочки, несмотря на МАССИВНУЮ реакцию сообщества - если бы у меня был пятицентовик за каждый раз, когда кто-то сказал: «Ну, просто поставьте его за флаг», я бы набирал это с лодки. Но это было правильное решение, потому что нам нужно было угадать, что произвел (null)?.prop , и мы абсолютно точно предположили бы null (а не undefined ), и мы ' Я буду жить с другим непрекращающимся бременем сложности, чтобы понять это. Здесь есть сильная противоположная сторона: никто не застрял, сидя на базе кода из 3 миллионов строк, заполненных использованием ?. где они зависят от этого, иногда производя null , без возможности даже выяснить, как перейти к другому поведению undefined .

Bloomberg внедрил частные поля, потому что они были очень рады получить эту функцию и хотели внести свой вклад в TypeScript. Если бы их не было в этой ситуации, мы бы сами реализовали эту функцию, как и все остальное.

В целом, я бы сказал, что график JavaScript очень и очень длинный, и что реально вы можете написать хороший и эргономичный JavaScript в 2020 году без использования синтаксиса 2024 года, точно так же, как вы могли бы написать хороший и эргономичный JS в 2016 году без использования синтаксиса 2020 года. Никого не мешает неспособность использовать синтаксис, который еще даже не имеет окончательно определенной семантики; в этот момент это просто воображаемое программирование.

Более того, нет даже 100% уверенности в том, что текущее предложение полей класса и все его детали дойдут до стадии 4 в его текущей форме (особенно сейчас, когда компания-член TC39 агитирует полностью отказаться от предложения и заменить его. с другим). Я бы предположил 95% уверенности, но в целом даже реализация предложения этапа 3 сопряжена с определенным риском. Однако вероятность дальнейших изменений после этапа 3 очень мала, поэтому я считаю, что текущая политика TS является хорошей.

теперь, когда есть компания-член TC39, агитирующая полностью отказаться от предложения [поля класса] и заменить его другим

Интересно, заметьте ссылку на это?

Вот идея: возможно, команда TS могла бы потратить некоторое время на улучшение системы подключаемых модулей, чтобы дать авторам подключаемых модулей четкий API, который подключается как к времени компиляции, так и к времени intellisense-времени языка-сервера-протокола. Это позволит третьим сторонам реализовать любые экспериментальные функции, которые они хотят, включая новый синтаксис, и по-прежнему иметь работающий intellisense внутри IDE и текстовых редакторов.

Последнее, что я проверял, ttypescript - это единственный способ tsconfig.json , и он не подключается к intellisense каких-либо IDE, поэтому возможность сторонних разработчиков создавать значимые функции, которые хорошо интегрируются с существующих инструментов, таких как VS Code, еще нет. Мы не хотели бы отказываться от нашего приятного опыта VS Code, переключившись на ttypescript и полагаясь на вывод терминала, в то время как VS Code не может понять синтаксис и выдает ошибки.

Тогда TypeScript может сосредоточиться на стабильных функциях и позволить сторонним разработчикам создавать или использовать рискованные экспериментальные функции (так же просто, как в экосистеме Babel).

Интересно, заметьте ссылку на это?

https://github.com/microsoft/TypeScript/pull/30829#issuecomment -541338266

Есть очень ограниченный набор синтаксических вещей, которые вы можете делать с помощью плагина Babel; в основном парсер уже должен это поддерживать. Например, выражение "плагин" do по-прежнему требует логики в самом ядре Babel: https://github.com/babel/babel/blob/master/packages/babel-parser/src/parser /expression.js#L991 На самом деле он ничем не отличается от переключателя командной строки.

Есть ли проблема, которую можно решить для методов и средств доступа частного класса?

@RyanCavanaugh

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

Я не думаю, что так должно происходить, и могу представить, что это вредит всему сообществу. Если декораторы достигнут стадии 3, я считаю разумным выделить время для обновления до новой версии декораторов. Может поддерживаться как какое-то время, может быть жестким переключением и отказом от устаревших декораторов в TypeScript 4+. Я не знаю разницы между старыми и новыми декораторами, потому что не использую их (ну, экспериментальная функция). Но я думаю, что затронутые проекты должны работать над предложением, если предложение не соответствует их потребностям. Так лучше для всех. TypeScript - неподходящее место для разжигания войны за устаревшие и экспериментальные функции.

Сожалею, что попал сюда: /

@RyanCavanaugh

Есть очень ограниченный набор синтаксических вещей, которые вы можете делать с помощью плагина Babel; в основном парсер уже должен это поддерживать.

Правда. Но в интересах сравнения с TypeScript в Babel вы можете разветвить только парсер и настроить babel.config.js для использования пользовательского синтаксического анализатора и любых пользовательских плагинов синтаксиса, которые вы создаете. Да, это большая работа (особенно изучение того, как добавить новый синтаксис в первый раз), но я не знаю ни одного эквивалентного варианта для TS, и, конечно же, в Babel намного проще писать плагины преобразования на основе существующего синтаксиса. Я не уверен, каково текущее состояние параметров настройки в TypeScript, но когда я последний раз изучал его пару лет назад, казалось, что не было возможности расширить его, кроме как разветвить все это.

Попробуйте это: https://github.com/dsherret/ts-morph

Хеш для рядовых IMO уродлив и сбивает с толку. Это жестко принудительно, потому что иначе их реализовать невозможно. Нет такого шага сборки, как в TS. Эффект состоит в том, что код просто забивается символами для очень небольшого выигрыша от «жесткого приватного», поскольку люди думают, что это «правильный» способ написания JS, поскольку многих людей учат, что по умолчанию все должно быть приватным.
Прежде чем включать его в стандарт, должно было быть больше предложений, особенно когда есть очевидные разногласия по этому поводу.

@ robot56 по умолчанию вещи должны быть приватными. Их учат, что все должно быть доступно через рефлексию, что на самом деле никому не идет.

@ljharb Да, должны. Однако, когда способ объявить частное - это бросать хеш-символы перед переменными, «правильный» способ создать класс в JS означает научить людей просто помещать хеш-коды перед переменными-членами. Не только при их объявлении, но и при обращении к ним. Это особенно сбивает с толку, если вы переходите с других языков. Моя первая мысль, когда я увидел что-то вроде this.#x = this.#something(); и объявление в классе, было то, что хеш был отдельным от самой переменной. Никогда бы не подумал, что это модификатор. Подчеркивание для публики, это тоже кажется обратным. На самом деле это не имеет отношения к TS, но я думаю, это просто раздражающая тирада.

Да, изучение новых вещей, когда человек закреплен в знакомстве, может быть приспособлением. Я верю, что сообщество JS продолжит обучение!

(хэш является частью самой переменной, имя this.#x не "x, но частное", а фактически #x , уникальное значение в этой лексической области видимости)

Да, изучение новых вещей, когда человек закреплен в знакомстве, может быть приспособлением. Я верю, что сообщество JS продолжит обучение!

То, как вы это выразили, звучит так, как если бы это было изучением чего-то, что добавляло нашей мудрости программирования, в то время как это просто еще одна причуда JS, которую нужно запомнить: D