Несколько предложений расширяют существующий синтаксис классов в JavaScript новой функциональностью. Эта статья объясняет новый синтаксис публичных полей классов в V8 v7.2 и Chrome 72, а также грядущих приватных полей.
Вот пример кода, который создает экземпляр класса IncreasingCounter:
const counter = new IncreasingCounter();
counter.value;
// logs 'Getting the current value!'
// > 0
counter.increment();
counter.value;
// logs 'Getting the current value!'
// > 1Отметим, что обращение к value выполняет некоторый код (вывод сообщения в лог) перед тем, как вернуть значение. Теперь спросите себя: как бы Вы реализовали этот класс на JavaScript?
Классы ES2015
Ниже пример того, как класс IncreasingCounter может быть реализован с помощью синтаксиса ES2015:
class IncreasingCounter {
constructor() {
this._count = 0;
}
get value() {
console.log('Getting the current value!');
return this._count;
}
increment() {
this._count++;
}
}Класс предоставляет геттер value и метод для инкремента значения в прототипе. Более любопытно, что класс имеет конструктор, который инициирует свойство _count и выставляет его начальное значение в 0. Сейчас мы используем префикс подчеркивания, чтобы обозначить, что _count не должен использоваться напрямую вне класса, но это просто соглашение; в действительности это не приватное свойство, а эта семантика не определена в самом языке.
const counter = new IncreasingCounter();
counter.value;
// logs 'Getting the current value!'
// > 0
// Nothing stops people from reading or messing with the
// `_count` instance property.
counter._count;
// > 0
counter._count = 42;
counter.value;
// logs 'Getting the current value!'
// > 42Публичные поля классов
Новый синтаксис для публичных полей позволяет упростить определение класса:
class IncreasingCounter {
_count = 0;
get value() {
console.log('Getting the current value!');
return this._count;
}
increment() {
this._count++;
}
}Свойство _count теперь лаконично объявлено в начале класса. Нам больше не нужен конструктор только для того, чтобы определить некоторые поля. Отлично!
Тем не менее, _count — все еще публичное свойство. А в этом конкретном примере мы хотим предотвратить обращение к этому полю напрямую.
Приватные поля классов
Именно здесь на помощь приходят приватные поля. Новый синтаксис для приватных полей схож с синтаксисом публичных полей, за исключением того, что Вы помечаете их как приватные, используя символ #. Вы можете думать, что # — это просто часть имени поля:
class IncreasingCounter {
#count = 0;
get value() {
console.log('Getting the current value!');
return this.#count;
}
increment() {
this.#count++;
}
}Приватные поля недоступны вне тела класса:
const counter = new IncreasingCounter();
counter.#count;
// > SyntaxError
counter.#count = 42;
// > SyntaxErrorСтатические свойства
Синтаксис полей классов может быть использован для создания публичных и приватных статических свойств и методов, как показано ниже:
class FakeMath {
// `PI` is a static public property.
static PI = 22 / 7; // Close enough.
// `#totallyRandomNumber` is a static private property.
static #totallyRandomNumber = 4;
// `#computeRandomNumber` is a static private method.
static #computeRandomNumber() {
return FakeMath.#totallyRandomNumber;
}
// `random` is a static public method (ES2015 syntax)
// that consumes `#computeRandomNumber`.
static random() {
console.log('I heard you like random numbers…')
return FakeMath.#computeRandomNumber();
}
}
FakeMath.PI;
// > 3.142857142857143
FakeMath.random();
// logs 'I heard you like random numbers…'
// > 4
FakeMath.#totallyRandomNumber;
// > SyntaxError
FakeMath.#computeRandomNumber();
// > SyntaxErrorУпрощение работы с подклассами
Преимущества нового синтаксиса полей классов становятся более очевидны при работе с подклассами, которые вводят дополнительные поля. Представим следующий базовый класс Animal:
class Animal {
constructor(name) {
this.name = name;
}
}Чтобы создать подкласс Cat, который добавляет новое свойство для экземпляра, ранее требовалось обратиться к super(), чтобы вызвать конструктор базового класса Animal перед тем, как создать это свойство:
class Cat extends Animal {
constructor(name) {
super(name);
this.likesBaths = false;
}
meow() {
console.log('Meow!');
}
}Здесь много шаблонного кода только для того, чтобы указать, что коты не очень любят принимать ванну. К счастью, новый синтаксис полей классов избавляет от необходимости определения этого конструктора с неуклюжим вызовом super():
class Cat extends Animal {
likesBaths = false;
meow() {
console.log('Meow!');
}
}Итого
Публичные поля классов доступны, начиная с V8 v7.2 и Chrome 72. Скоро планируется релиз и приватных полей классов.
Комментарии (70)
gnaeus
02.02.2019 14:30+6Больше всего, конечно, смущает синтаксис с решетками. Потому что ломается совместимость с TypeScript, в котором используются ключевые слова
private/public/protected.
Да и в самом JavaScript эти слова зарезервированы. Правда теперь уже получается, что зря зарезервированы.
cerberus_ab Автор
02.02.2019 14:50+1Это просто синтаксис меньшего зла ) комментарий по этому поводу
gnaeus
02.02.2019 15:19+2"Так не доставайся ж ты никому!" — весьма распространенное явление, когда в деле замешаны всяческие комитеты.
Часто бывает нужно не private, а internal (видимость на уровне модуля или NPM-пакета). И теперь приходится для private использовать #, для internal — Symbol и computed properties.
А можно просто настроить минификатор, чтобы он манглил все свойтсва объектов, начинающиеся с нижнего подчеркивания, как делали и раньше, и не насиловать себе мозг.
Имхо, они приняли поспешное решение. И теперь нам всем придется с этим жить.
cerberus_ab Автор
02.02.2019 15:56+1Да, ситуация несколько досадная. Учитывая, что часто JavaScript — не единственный язык, на котором приходится писать… и в нем все больше и больше специфики.
Возможно, многие читали этот issue о кейворде: там довольно много обсуждения и недовольств.
Например, мол сложно внедрятьThink of what you might need to do to make that work.
- 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?
- 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.
gnaeus
02.02.2019 16:10Кстати, а что будет, если я добавлю новый метод в прототип класса (да, monkey patching)? И попытаюсь прочитать приватное поле:
class Test { #foo = 123; } Test.prototype.getFoo = function() { return this.#foo; }justboris
02.02.2019 16:33Не сработает. Можно самому в этом убедиться, если включить в хроме флаг "Experimental JavaScript" и попытаться запустить этот код. При попытке вызова getFoo выскочит ошибка
Uncaught SyntaxError: Undefined private field #foo: must be declared in an enclosing class
cerberus_ab Автор
03.02.2019 01:22Тоже об этом подумал ) Но синтаксис приватных полей класса работает только внутри тела определения класса.
Sabubu
03.02.2019 07:12Доступ к приватному полю ограничивается на уровне расположения в исходном коде: он возможен только между открывающий и закрывающей скобкой блока class. Если вы, например, вызовете анонимную функцию, которая определена внутри class (неважно, откуда вызовете) — то у нее будет доступ к приватным полям. Если же эта функция определена на пределами класса — то доступа не будет.
symbix
03.02.2019 03:05+1What do you mean by "encapsulation" / "hard private"?
It means that private fields are purely internal: no JS code outside of a class can detect or affect the existence, name, or value of any private field of instances of said class without directly inspecting the class's source, unless the class chooses to reveal them. (This includes subclasses and superclasses.)
This means that reflection methods like getOwnPropertySymbols must not reveal private fields.Ох уж эти комитетчики. Одни теоретики. Как они представляют себе работу persistance/hydration с таким подходом? Даже пусть не ORM, а банальную сериализацию? А, кстати, что будет видеть JSON.stringify? :-)
xRevolveRx
02.02.2019 14:52Мне кажется для TypeScript это не смертельно. Ведь они не дождались нормальной реализации стандарта и начали нашпиговывать язык своими, как правило не очень то и критичными фичами.
gnaeus
02.02.2019 15:39А private — критическая фича? Вон в питоне как-то живут без нее. И хорошо живут. Все это нужно только для самодисциплины разработчиков.
Вот декораторы — это существенное увеличение выразительности языка. Но они зависли в недрах комитета на долгие годы. И неизвестно, вылезут ли из stage-2.
А есть еще такая крутая штука как pipeline operator (тоже несколько лет в stage-1). С ней работа в функциональном стиле упростилась бы в разы. Но без статической типизации она превращается в тыкву. А команда TypeScript, обжегшись на взаимодействии с комитетом по поводу декораторов, отказалась реализовывать этот оператор =(xRevolveRx
02.02.2019 16:03-8Я с вами согласен. Я на PHP тоже не использую private ибо толку от него ноль. Только видимость защищенности данных.
Zibx
02.02.2019 18:02+3Языку со времён ES5 не хватало только возможности заводить типизированные переменные в целях увеличения производительности, эдакое развитие в сторону ActionScript — сейчас скорость бы уже сравнялась с нативными языками, но нет, теперь у нас есть особые классы, куча синтаксиса написания функций, замыкания на уровне блоков чтоб GC подавился. Всё кроме переменных можно было решить транспайлерами, даже перегрузку операторов которую давно жду.
serf
04.02.2019 07:11TypeScript является суперсетом ES/JS, то есть они поддержат изменение github.com/Microsoft/TypeScript/issues/9950, но когда придет время. Обычно TS вводит поддержку новых штуковин начиная со stage 3. Но видимо в этот раз они не спешат ввиду притиворечивости текущего состояния стандарта:
— github.com/tc39/proposal-class-fields/issues/100
— github.com/tc39/proposal-class-fields/issues/144
— github.com/tc39/proposal-class-fields/issues/177
— github.com/tc39/proposal-class-fields/issues/203
— и тд
immchenko
02.02.2019 15:01+10Тоже грустно без private / public / protected. С решеткой какой-то маня-монёвр уровня IE
TheShock
02.02.2019 19:33+2Сейчас мы используем префикс подчеркивания, чтобы обозначить, что _count не должен использоваться напрямую вне класса, но это просто соглашение;
Ну и что? В Джавах и Шарпах тоже можно поменять и прочитать приватное свойство через рефлексию и его не читают «потому-что соглашение». И читают, когда в этом действительно есть необходимостьserf
04.02.2019 07:16И читают, когда в этом действительно есть необходимость
При этом явно оттадавая себе отчет в том что рефлексия медленная и в том что даже следующий минорный релиз допустим библиотеки которая «хакается» рефлексией может сломать их хаки тк приватные поля не являются частью контракта.TheShock
04.02.2019 07:20+1И? Джаваскрипт медленный, а поля, помеченные «просто соглашением» как приватные не являются частью контракта.
pesh1983
02.02.2019 21:46+2Мне одному кажется странным использование префикса вместо зарезервированного слова, как это сделано во всех остальных нормальных языках?
justboris
02.02.2019 21:51достаточно почитать комментарии выше, чтобы убедиться, что нет, не одному.
pesh1983
02.02.2019 21:56Где-то и когда-то развитие языка свернуло явно не туда (
justboris
03.02.2019 01:46+1Я себе это представляю как-то так:
TC39: дорогие разработчики, какие новые фичи языка вы хотите?
Сообщество: приватные поля! Больше строгости в наш Javascript!
TC39: тут такое дело… из-за обратной совместимости и других загвоздок приватные поля должны обладать специальными именами, модификатор private сделать не получится.
Сообщество: ну и не очень-то нам нужно такое решение
Интересно, как в этой ситуации выкрутится Typescript, у которого интеграция с ЕS-приватными полями уже значится в планах на будущее
pesh1983
03.02.2019 19:16+1TS может сказать, что у нас будет отдельный модификатор для приватного поля, но мы поддерживаем и синтаксис js, однако рекомендуем использовать нормальный подход, который предоставляем мы. Я бы использовал их вариант.
TheShock
03.02.2019 01:24В динамическом языке сложновато придумать, как добавить модификатор приват, т.к. информации про свойство как в статических языках, по сути, нету.
Zibx
03.02.2019 02:53Модификатор добавить легко, сложнее придумать ту напасть от которой нам нужно будет изолироваться с его помощью. Единственный кейс который я вижу — коммерческие библиотеки собранные в бинари, но и тут для «защиты» сейчас имеется ровно столько же инструментов.
Sabubu
03.02.2019 07:14Приватные поля придуманы не для защиты коммерческих секретов, а для инкапсуляции, которая упрощает понимание кода и повышает его качество и надежность.
pesh1983
03.02.2019 11:56+1Заменяете приватное свойство соглашением. Так уже давно используют нижнее подчеркивание. Мало того, что оно решает проблему (используешь приватные свойства — ССЗБ, разработчик кода не гарантирует совместимость). Так ещё и помогают, когда нужно поменять что-то в сторонней библиотеке, а нормальной возможности это сделать нет. Тогда на свой страх и риск. Но зато возможность есть, а это лучше ее отсутствия.
pesh1983
03.02.2019 11:35Вы явно объявляете свойство при объявлении класса. Не совсем понимаю, какие тут проблемы могут быть, если вы явно свойство объявили. Я так же не понимаю, чем объявление приватного свойства с префиксом с точки зрения реализации концептуально отличается от объявления с ключевым словом.
xPomaHx
03.02.2019 11:59+1Так и не смог понять зачем вообще нужно делать приватные поля кроме как разве для работы ide, если ты работаешь с кодом как с либой, то кроме как, то что есть в документации ты нечего как бы и не сможешь использовать. А если приходится лезть внутрь кода то какая разница, тебе и так и так придется разбираться в нем, да мб легче будет разобраться в коде, но если разраб не пишет коменты или доки, то он так же может и приватными поля не делать.
gnaeus
03.02.2019 12:37Еще бывает нужно для ABI при динамической линковке. В смысле, чтобы при компиляции *.dll / *.so / whatever не экспортировать метаданные о приватных полях. Но для этого нужна компиляция хотя бы в байт-код. Таким образом вы правы — для JavaScript это не нужно =)
zim32
03.02.2019 12:39А зачем к примеру в C++ есть ключевое слово volatile. Чтобы уменьшить вероятность что что-то пойдет не так.
angly
03.02.2019 13:28К слову, сейчас это предложение находится на 3 стадии принятия в стандарт.
Опробовать в других браузерах можно с помощью бабеля, используя либо плагин@babel/plugin-proposal-private-methods, либо пресетstage-3.
1c80
А через модули не проще разве? можно экспортнуть только то, что надо, остальное будет закрыто.
Djaler
как вам модули помогут ограничить доступ к полям классов?
1c80
ну вынести эти поля в константу и не эскспортировать её, а в классе работать через геттер и сеттер
Djaler
Во-первых, интересно представить, как вы себе представляете сеттер для константы. Ну это ладно, допустим, вы имели в виду переменную. Но что делать с тем, что у класса может быть не один экземпляр?
gnaeus
Вероятно, имелось в виду, что можно вместо классов использовать фабрики объектов. И публичные поля и методы пихать в объект, а приватные оставлять в замыкании. Ну или все поля / методы задавать в конструкторе, ничего не оставляя в прототипе. Хотя это все дичь конечно =)
Zibx
Все приватные выносить в соседний объект и ссылку хранить в замыкании. Основной вопрос — зачем весь этот цирк если дебаггером всё равно можно остановиться внутри функции объекта и изучить\модифицировать всё приватное.
xRevolveRx
На backend как это сделаете?
TheShock
Если есть доступ к коду — то так же легко подключается.
Если нету доступа, то какая разница — приват там или паблик
xRevolveRx
Так нет у Вас доступа, если вы не разработчик, а если есть — то вы ковыряете просто front-end. А для чего на фронте делать приваты???
TheShock
А для чего на беке делать приваты? Если доступа нет — я и паблики не посмотрю. А если доступ есть — приваты мне не помешают.
xRevolveRx
Так от чего они защитят? От вашего чинарика в зубах?
TheShock
Что?
xRevolveRx
Я к тому, что я не обязан был 10 лет писать приватные поля в JS потому что хватало и замыканий; и теперь не обязан слушать людей, которые утверждают, что это критически нужно для дисциплины и понятности API класса. Всю жизнь все объекты DOM в JS были таки нашпигованы кучей оснастки и расконсоливание об этом прекрасно рассказывает. На сервере, кстати, гораздо проще объекты и сами классы поэтому, я по привычке даже не задумаюсь об этом. Минусуете, как будто 300 лет в лесу жили.
TheShock
Минусуют, потому что вы речь построить не можете.
Sabubu
Приватные поля не для защиты от просмотра их разработчиком… это не права доступа на файлы. Приватные поля нужны для реализации инкапсуляции, которая служит для таких целей:
Не понимаю, зачем вы тут вдвоем пытаетесь бахвалиться невежеством и непониманием основ программирования, которые изучают на первом курсе.
TheShock
Эмс. Вы веткой ошиблись? Я как раз и старался объяснить человеку, что «приват» модификатор никак не защищает данные. Более того, с разделением «на сервере защищает, а на клиенте — нет». Это вообще не имеет никакой логики. Я задавал наводящие вопросы и надеялся, что человек дойдет до этого.
Жаль, что вы сразу бросились в оскорбления не разобравшись в ситуации.
А модификатор private, который физически не дает доступа к данным считаю ненужным и даже, иногда, вредным. Для любого программиста достаточно модификатора private, который является удобным способом записать сограшение, что переменная или метод приватны, а проверка пусть происходит на стороне IDE или линтера, как строгая рекомендация.
И да, то, что модификатор «приват» НУЖЕН для реализации инкапсуляции — поверхностное мнение от попсового (упрощенного) определения инкапсуляции.
1c80
да, переменную имел ввиду, по остальному уже особенности архитектуры приложения,
где то конечно и не прокатит такой метод.
justboris
Есть такой старый добрый паттерн "Модуль": сохраняем приватные значения в замыкании, возвращая наружу только публичное API.
Что-то похожее можно сделать и на современных ES-модулях
Djaler
ну это костыли. Я уж не говорю про удобство этого дела
justboris
Кому как. Для меня это давнее и вполне логичное использование фич языка.
ankh1989
Сей паттерн ест сильно много памяти по сравнению с прототипами. Замыкания не бесплатны.
justboris
А есть подтверждение этой информации?
Например, я вижу, что Redux использует как раз замыкание для своего createStore. Сокращенно код выглядит как-то так.
Библиотека используется много где, и в React и Angular проектах, так что если бы здесь были заметные проблемы с производительностью, то это бы давно заметили.
VolCh
стор обычно создаётся один раз в приложении, а есть объекты, которые создаются тысячами
Sabubu
Так это костыли для имитации современных ES-модулей. Имеет смысл применять только, если требуется обеспечить поддержку большого числа браузеров.
aamonster
А современные ES-модули внутри не устроены так же, как этот костыль? С классами, помнится, именно так.
Sabubu
Модуль это не класс и вы не можете создать несколько экземпляров модуля с разными настройками, например.
1c80
Почему? могу вроде как, но это каша будет, проще в конструкторе разные настройки применить в зависимости от условий.
Но решетки тоже не плохо, я не против них.
кстати интересно, как бабель с решетками поступает.