Комментарии 70
Запускать с --expose-gc на node>=14
let bigObject = {
name: 'Backbencher',
};
const aBigObjectRef = new WeakRef(bigObject);
const callback = () => {
console.log(aBigObjectRef.deref().name);
bigObject = undefined;
};
(async function() {
await new Promise((resolve) => {
setTimeout(() => {
callback(); // Гарантированно напечатает "Backbencher"
resolve();
}, 2000);
});
setTimeout(() => {
// важно триггерить gc тут, а не строкой выше
// https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WeakRef
if (global.gc) {
global.gc();
}
callback(); // Нет гарантий, что напечатается "Backbencher"
}, 5000);
})();
//...
const item = itemsById[id] ??= {};
//...
вместо
//...
if (itemsById[id] === undefined) {
itemsById[id] = {};
}
const item = itemsById[id];
//...
const item = itemsById[id] || {};.
И кому это нужно?
для этого случая лучше бы занесли setdefault как в питоне:
item = itemsById.setdefault(id, {})Чувствую скоро JS скатится в что-то подобное ICQ для 12-летних
const x = y ??= z#@->--0 &&= %$!(XXX) * wtf function getSet(target, key, defaultValue) {
if (target[key] === undefined) {
target[key] = defaultValue;
}
return target[key];
}
const item = getSet(itemsById, id, {});
так речь о том, чтобы это было в языке.
Своими ручками можно что угодно наваять, но зачем внедрять в язык всякие синтаксические конструкции, которые ни разу не упрощают жизнь, вместо нормального API для соответствующих объектов-типов-классов.
Вот добавили Set, ну и что? Совершенно непонятно, как его использовать без дюжины дополнительных функций, таких как union, difference, intersection… почему не добавить их сразу в АПИ класса Set? Нет, нужно больше модулей npm видимо… Я бы на месте разработчиков этих стандартов первое что сделал, это затащил в стандарт lodash API, хотя бы процентов этак 90. Это было бы намного полезнее, чем изобретать ещё один велосипед для решения проблемы, которую решают созданием новой проблемы.
const onlyUniqueArray = [...new Set(nonUniqueArray)]
Дык кто спорит, что это можно. А вот чтобы к примеру найти общие элементы двух массивов:
common = set(list1).intersection(list2)Это на питоне, а попробуйте на ЖС написать. А, ну да — идёте в https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set#Implementing_basic_set_operations и копируете. И кто там — mayorovp — упрекал меня в копировании из доков. А что ещё делать остаётся-то. И вот все копируют, копируют, копируют… Все проекты начинаются с кучи бойлерплейта, который давно пора уже занести в язык, но не можно потому, что иначе ваше [] + [] === '' — ключевая фича ЖСа 30-летней давности — не будет работать.
Не слишком ли там простой код, чтобы его копировать? Когда мне нужно что-то из перечисленного там — я беру и пишу код, даже не задумываясь где его можно найти и откуда скопировать...
Все проекты начинаются с кучи бойлерплейта, который давно пора уже занести в язык
Что же до сих пор никто не опубликовал его в виде библиотеки?
но не можно потому, что иначе ваше [] + [] === '' — ключевая фича ЖСа 30-летней давности — не будет работать
То есть те функции по ссылке выше "ломают" сложение массивов? Вроде же нет. Не вижу связи между началом вашего комментария и его окончанием.
я беру и пишу код, даже не задумываясь где его можно найти и откуда скопировать...
и в результате появляется 100500 тыщ копий одного и того же кода, который вполне бы мог существовать в builtins, только если вы, возможно, человек опытный и можете сразу правильно написать, то сотни джунов пишут всё новые и новые копии с багами.
Что же до сих пор никто не опубликовал его в виде библиотеки?
угу, вот поэтому типичный проект на ноде и устанавливает пару (десятков) тысяч библиотек. Которые ещё и отличаются версиями, потому что какой-то джун изначально написал свою "копию", которая задачу решает либо на 80%, либо просто криво, поэтому кто-то форкнул и теперь их две, и т.п.
То есть те функции по ссылке выше "ломают" сложение массивов?
Вы только буквально умеете понимать?
Для буквоедов объясняю. Меняя какую-то функциональность в языке, которому 30 лет, вы сломаете кучу проектов куче людей. Это очевидно. Рассматривая приведённый пример [] + [] === '', если вы захотите избавиться от данного WTF, то он наверняка сломает кучу проектов, потому что хоть это и выглядит совершенно неразумно, однако же по разным причинам куча кода основана на этом именно в таком виде. И это главная проблема ЖС — любой новый проект на нём, ну просто никак, не может не учитывать ВТФы, которым 30 лет.
Вот как часто вы используете оператор "=="? более того, во всех проектах, которые я видел, есть правило eslint не использовать этот оператор. Ну так уберите его из языка, если с ним столько проблем, в чём проблема? Ведь могли же раньше "use strict", придумайте что-нибуть аналогичное питоновскому, условно
from __future__ import double_equals_is_strict_equalsи можно будет писать а == б вместо а === б. (Опять же, это пример.)
Но нет, зато вот мы введём какой-то мутный private, который 80% разработчикам за всю жизнь не пригодится ни разу. И сделаем его через Ж #, потому что "совместимость" же.
Когда я смотрю на сайт https://node.green, думаю — о, вот круто, столько всего понафигачили, аж 5 минут грузится. А ведь на самом деле за этим нафигачением стоит лишь одно — бардак. Здесь покосилось — гвоздь забили. Там покосилось — костыль забили. Всё здание ЖС держится пока на трёх костылях — основа языка 30-летней давности, огромная распространённость в вебе и, надо отдать должное, инфраструктура, одна из самых развитых (отчасти и в силу того, что нода не так давно набрала популярность и пользуется современными достижениями — гитхаб, репозитории пакетов и тп. постольку, поскольку этот путь уже был пройден другими ранее). Но я хорошо помню, как больше 10 лет назад на Опеннете, в треде про РНР, я писал — ребята, бросьте вы это фуфло, переходите на ЖС в качестве бэкенда. И мне отвечали: да ты сумасшедший! РНР классный язык, бла бла бла! но… через полгода гугл объявил о том, что V8 будет использоваться для консольного скриптинга.
И где теперь РНР? Удел маргиналов (слегка утрируя, конечно). Хотя в последнее время довольно неплохо развивается… Я впрочем не хочу делать прогнозы. К тому же, я прекрасно понимаю, что человек, всю жизнь пишущий на ЖС, просто не думает об этих проблемах, воспринимая их как данность. Но всё познаётся в сравнении.
Конкретно для {} такой подход может работать, но иногда значение по умолчанию нужно сначала вычислить, и это вычисление является дорогим. В таком случае приходится вторым параметром передавать функцию — вот только лично для меня стрелочная функция визуально "грязнее" оператора ??=.
И ради таких крайних случаев вводить новый оператор, да. То есть, целых три. Старый добрый if видимо скоро вообще станет ненужным ??=)))
Язык с самым большим числом WTF и способов отстрелить себе ногу станет ещё разнообразнее.
Новый оператор вводится прежде всего для согласованности с другими частями языка.
У нас есть операторы + и +=, есть - и -=, есть * и *=… а вот логическое операторы почему-то были без пары.
Хмм. Язык, в котором кругом одни несогласованности, вдруг задумался о согласованности оператора, существовавшего 30 лет ??=))
Когда я смотрю проекты, делаемые разными командами, ощущение такое, что у каждой свой ЖС. У одних ;, у других нет. У одних const f = (a) => a, у других function f(a) { return a} и т.д. и т.п.
Даже банально примеры из доков библиотек в проект не вставить без того, чтобы ручками половину править, чтоб eslint не обгадил.
С этим бы лучше разбирались.
Ладно. Не моё дело. Зато я счастлив, что мне не приходится писать на ноде каждый день. ||=))
Хмм. Язык, в котором кругом одни несогласованности, вдруг задумался о согласованности оператора, существовавшего 30 лет ??=))
Предлагаете на них молиться, вместо того чтобы исправлять? Особенно когда обратная совместимость не мешает, как в случае с этими операторами?
Даже банально примеры из доков библиотек в проект не вставить без того, чтобы ручками половину править, чтоб eslint не обгадил.
А на других языках вы что, копируете примеры из доков без исправления? Ужас...
Я преподаю на курсах веб-программирования, и знаете ли, в разделе про ЖС 80% времени приходится объяснять людям, что операторы в ЖС далеко не всегда делают то, что от них ожидаешь. Особенно после питона.
Да, оно не мешает, но когда у вас 30 лет назад был запорожец и вы по одной запчасти меняете то от мерседеса, то от лексуса, то от велосипеда...
копируете примеры из доков без исправления?
и что ужасного? Если мне (или моим студентам) нужно быстро создать какой-нибудь нечасто используемый реакт хук или даже простую форму с формиком, то что, по-вашему, вы всё это пишете ручками с нуля? Не врите хоть самому себе.
Конечно использовать пример один к одному не получится, но править в них синтаксис (в добавок к логике) занятие то ещё.
нечасто используемый реакт хук
или даже простую форму с формиком
Вы не поверите, но… да пишем с нуля. Копирование каких-то кусков кода, найденных в сети, вещь исключительно редкая. Это:
- или поиграться с готовыми примерами
- или реализация чего-то хитрого (например мне нужно было кривые Безье по геогр. точкам делать). Но в этом случае код сильно правится под нужды
- либо что-то завязанное на тонкости (например какие-нибудь побитовые операции, какие-нибудь константы из криптографии, код преобразующий даты разных календарей и пр.). По сути это вещи подразумевающие под собой не просто логику, а глубокое знание какой-нибудь предметной области, которой у вас ещё нет
Хоть и не вам комментарий был адресован :) но вы сами и признали, что копируете.
Да, всё так.
Типичная для меня ситуация. При работе со студентами, скажем я даю задание использовать реакт хук useCallback, и вот они логично берут этот пример: https://reactjs.org/docs/hooks-reference.html#usecallback
Теперь я им объясняю, что можно также использовать глобальный стор, и вот они идут например сюда https://redux-toolkit.js.org/api/createAsyncThunk и берут этот пример. И спрашивают, это точно ЖС? там function, тут const, там ; есть, тут нет ...
код сильно правится под нужды
У кого-то, видимо, со словом "копировать", когда его говорит кто-то другой, стойкая ассоциация "вставить как есть". А на самом деле, просто подумайте, сколько кода вы напечатали на клавиатуре, а сколько вы скопировали, и впоследствии изменили. Любая вещь, которую вы раньше не делали — вы идёте в документацию, и если там есть шаблон, было бы тупо его не скопировать (и изменить), а напечатать всё то же самое пальцами, не так ли? Если вы раньше делали (что-то больше чем пара-тройка строк, в каком-то другом проекте), было бы тупо не скопировать (и естественно изменить).
А теперь представьте, что во всех этих кусках вы правите не только логику, но ещё и синтаксис. Ну хорошо, ; расставит eslint --fix (или prettier). И много чего другого он сумеет. Но кое-что и не сумеет. А кое-где так и вообще сломает (как например function vs () => {} в классах). Так что… Нет, ну если вы не против этим заниматься, пожалуйста. Просто я разрабатываю в другом мире, где почти всех этих проблем нет.
Нравится Python — пишите на нем сколько влезет и учите ему студентов.
Мне он нравится и полностью устраивает, даже с учетом некоторых недостатков, но его достоинства выше крыши перекрывают его недостатки.
Вот мне например не нравится Python — я с ним дел вообще не имею и мне на класть что там творится с ним. Тоже самое касается Ruby и т.п.
Поэтому я не ною что язык плохой.
сколько кода вы напечатали на клавиатуре
99%
а сколько вы скопировали, и впоследствии изменили.
Сколько я скопировал чужого кода? < 1%.
Если своего, то много больше конечно.
вы идёте в документацию, и если там есть шаблон, было бы тупо его не скопировать (и изменить), а напечатать всё то же самое пальцами, не так ли?
По моему опыту чаще всего в документации бесполезный надуманный код, который не имеет смысла копировать. Копирую я скорее название метода\класса. Зачем мне их код?
А теперь представьте, что во всех этих кусках вы правите не только логику, но ещё и синтаксис.
Даже в тех случаях когда я и правда копирую чей-то код я его полностью переписываю под наши нужды. Меняю буквально всё — архитектуру, названия методов, условия, порядок операндов и многое другое. Мне вот если честно совершенно плевать на то какой там синтаксис. Я всё равно это в утиль спущу. У нас ведь есть code style, есть clean code нормативы, есть особенности проекта и многое другое.
Просто я разрабатываю в другом мире, где почти всех этих проблем нет.
Я боюсь представить что вы такое разрабатываете, что у вас прокатывает копипаста. Ну да ладно… бывают наверное проекты где можно и stack overflow driven development использовать.
Я боюсь представить что вы такое разрабатываете, что у вас прокатывает копипаста.
Я боюсь представить, что же за хомпейдж у вас такой, что 99% кода вы самолично напечатали в нём. Для проектов, ведущихся единолично, и в самом деле есть code style, есть clean code нормативы, есть особенности проекта и многое другое, которые кроме вас никому не интересно какие, так как кроме вас в них и нет никого. </sarcasm>
Конечно, сарказм — это лучший способ общения в хабре, доказано поколениями, но он немного мешает вашему собственному пониманию чужих мыслей.
Если в StackOverflow есть ответ на именно чёртову вашу проблему, то почему не скопировать? Зачем менять, если это конкретное решение конкретно в данном месте подходит? Да, это может быть, тот самый случай, случающийся раз в год, но это валидное решение. Вы принципиально будете всё менять? Впрочем, это всё совершенно не имеет никакого отношения к реальной проблеме.
Да, в конце концов, не проблема и поменять. Как я уже сказал, даже вручную может и не надо менять. Вопрос не в том, стоит в каком-то конкретном месте точка с запятой. Вопрос, что если у вас чуть больше чем один ваш хоумпейдж, и в каждой команде свои правила.
Не знаю откуда взялся homepage, возможно, я что-то проглядел. Вроде говорили о copy-paste в целом.
Зачем менять, если это конкретное решение конкретно в данном месте подходит?
- code style в проекте другой
- linters в проекте другие
- набор утилит \ хелперов \ whatever в проекте другой и часть "копипасты" не уместна
- принятые соглашения по написанию кода в проекте другие
- названия переменных должны отражать суть вашей предметной области, а не изначального автора
- нюансы задачи другие
- даже парадигма легко будет другой
- подходы к архитектуре и организации кода будут другими
- в конце концов чаще всего код написанный руками просто тупо лучше, чем абстрактный пример из сети
Просто так вставить код, прогнать его через prettier и запустить "git commit"? Мы с вами явно в параллельных вселенных обитаем. Чаще всего чужой код это просто пример, откуда программист черпает идею.
Вроде говорили о copy-paste в целом.
Нет, я говорил о том, что в разных местах разные стили. И как пример, что скопировать из одного места в другое просто так не получится, потому что, как вы сказали,
code style в проекте другой
А потом к моим словам о копировании прицепились (не вы). Может, плохой пример привёл. Я лишь хотел сказать, что code style в проектах настолько разный, что это по сути разные языки.
Предлагаю закрыть тему копипаста )))
Но вот ещё что хочу отметить. Вы использовали шаблоны? типа create-react-app, razzle etc. (к вопросу о чужом коде =) И вот, делаешь проект на подобном шаблоне, ну естественно там eslint prettier и все-все-все. Отдаёшь в руки доблестных солдат фронтенда. Через полгодика приходишь, ёмоё, что за хрень там. А просто задизейблили половину правил eslint по принципу "мне не нравятся ";" в каждой строке и я ниасилил разницу между лямбдой и функцией и всё пишу в функции, или int(``${var}`` + ``${var2}``) потому, что я просто низнаю что там за var и если вдруг не число, то не хочу делать проверку типа."
Чем больше разных возможностей отстрелить себе ногу, тем больше ног будет отстрелено.
Конечно, и на питоне можно завернуть, но всё-таки основные тривиальные случаи PEP8 стандартизирует. И до ревью значительно меньше вывертов доходит. (Хотя да, тоже можно задизейблить, вот только когда есть один стандарт, как-то к нему с большим уважением относятся.)
Вы использовали шаблоны? типа create-react-app, razzle etc.
Нет. Они никогда не решали мои проблемы. Только прятали под ковёр. Более того у меня есть большие претензии к качеству кода в CRA. Но я часто туда поглядывал в поисках идей — что бы добавить в сборку.
Чем больше разных возможностей отстрелить себе ногу, тем больше ног будет отстрелено.
Ну есть условные:
- go, python: есть только 1 способ сделать что-то, и не важно нравится ли он вам
- ruby, scala: есть 1001 способ сделать что-то, но теперь это ваши проблемы
JS/TS скорее из 2-й группы. В том числе за это я их и люблю. Люблю языки с вкусным сахаром. Они позволяют мне решать проблему, а не воевать с языком. Но да, это требует вложений. Т.к. этот язык во многом мой хлеб, мне этого времени не жаль.
… python: есть только 1 способ сделать что-то, и не важно нравится ли он вам
Не согласен. Право, не знаю, почему про питон ходят такие мифы, из-за There should be one-- and preferably only one --obvious way to do it. что ли? Так и тут не говорится про "только одну"… В питоне есть достаточное количество способов что-то сделать. А там, где больше одного не нужно, так зачем ещё?
Стиль кода более-менее стандартен, и тут вопрос "нравится-не нравится" обычно не возникает, потому что всё логично, бывают опять же исключения и крайние случаи, ну на то и есть всякие штуки, аналогичные eslint-disable-next-line.
Люблю языки с вкусным сахаром
Кто их не любит. И в питоне он есть.
А я ещё люблю языки с логичным АПИ, которое не надо каждый раз в документации проверять (впрочем, сейчас не так актуально, когда ИДЕ всё показывает), ну и конечно, функциональностью out of the box. Запуская голый питон, я могу сделать что угодно, от парсинга хтмла до НТТР-сервера, от десятичной математики до графики, причём мне не нужно изворачиваться в конфиге языка (!!! — кто вообще придумал, что синтаксис определяется внешними настройками?), чтобы включить удобоваримые модули, потому что они уже из коробки рациональные. Ну и… долго можно перечислять.
Я не говорю, что питон идеальный, есть косяки и в его АПИ, и есть вещи, которые в ЖС как инфраструктуре мне больше импонируют. Но в целом, питон как язык просто не сравним.
Поэтому мне как раз жаль времени, которое я трачу на решение тривиальных проблем в ЖС, которых нет в питоне, потому что увы, кроме питона мне приходится работать ещё и с ЖС ради зарплаты. =))
Хотя, скажу честно, есть и другой повод для меня работать с ЖС)) чтобы почувствовать прекрасное, нужно сравнить его с чем-то… не таким прекрасным. Если бы я не работал с ЖС, наверно я бы не любил питон так. Если бы я не работал с питоном, наверно был бы готов мириться, как и вы, потому что РНР (10 лет назад) было ещё хуже. Всё познаётся в сравнении.
Но в целом, питон как язык просто не сравним.
Не хочу ввязываться в holywar Python vs JS. Особенно в виду того, что я теперь точно за TypeScript, и к динамическим языкам едва ли когда-либо вернусь :) Считаю сам факт их существования ошибкой "на миллиард долларов". И это после 10 лет PHP и JS.
Если вам даже Python показался хорошим языком, то рекомендую взглянуть в сторону Ruby.
Не хочу ввязываться в holywar Python vs JS.
не холивара ради. Я отдаю себе отчёт, что вкусы у всех разные. И опыт тоже имеет значение. Отдав 18 лет вебу (профессиональной работы, не включая институт и поделки; из них 10 на питоне, до этого РНР и CGI/Perl, ну и куда же веб без ЖС), сейчас нет смысла вписываться например в Жаву или функциональщину. Как и вам в питон, по всей видимости. Поэтому я своё будущее связываю с питоном. И после перехода на питон, ни разу не пожалел =)
Про Руби я знаю, но не вижу в нём какого-либо сакрального смысла.
Опять же не ради холивара, на мой взгляд никаких особых преимуществ у статически типизированных скриптовых языков нет. Я всецело за подход питона: нужны типы — есть хинтинг. Как-то смотрю на этот хайп с TypeScript немного со стороны. Пока не зашло, слишком много проектов на ЖС.
рекомендую взглянуть в сторону Ruby.
Серьезно? Жесть, один из худших советов за последний год. Это недоразумение стремительно загибается и это логично.
Конкретно в приведенном коде, скорее всего, null там никогда не появится.
Потому что, я уверен, строка const item = itemsById[id] ??= {}; — это единственное место в коде, где внутрь itemsById кладётся какое бы то ни было значение. Другим значениям, вроде null, просто неоткуда взяться.
Чтобы каждый id класть в хеш только 1 раз, очевидно же.
Оттуда, что я узнаю паттерн. Других строчек кода, которые что-то кладут внутрь — нет, а та, которую я вижу, может положить только {} и ничего кроме {}.
Других строчек кода, которые что-то кладут внутрь — нет
Если их нет в однострочном примере, то как Вы заключаете, что их нет и не может быть в программе в принципе? Это очень произвольное допущение, мягко говоря. Если уж на то пошло, мы не видим здесь и инициализации хеша и присвоения идентификатора, так что же, предполагать, что они undefined?
В реальной программе я не буду гадать и просто проверю. Ну а в этом однострочном примере, как я уже говорил, я просто узнаю паттерн.
Этот паттерн строго исключает обращение к переменной itemsById отличным от itemsById[id] ??= {} образом.
Может быть, Вы перестанете уже демонстрировать неприязнь и объясните по-человечески? Я Вас чем-то обидел?
Позвольте заметить, что в данном примере замена не равноценная. Для равноценной замены старый код должен был выглядеть if (itemsById[id] === undefined || itemsById[id] === null). Сам недавно наткнулся на такую проблему.
Что сейчас не так?
const item = itemsById[id] ?? {};
const item = itemsById?.[id] || {}
Ещё ни одной статьи не обошлось без вопроса "ну почему не ключевое слово private?".
Авторы спеки даже специальный FAQ на эту тему написали.
Всё-таки будет справедливо заметить что в PHP это нормальный private
Считаю, что с тех пор, как в JS добавили костыли вроде 'class' и всяких стрелок, его надо было назвать JS++ или JS#. Ведь, если к седану приделать кузов, то это уже называется грузовик.
x &&= y лично я ожидаю как замену x = x && y, по аналогии с другими операторами присваивания, а не ту лабуду, которую они придумали.
x = x && y и x && (x = y) тождественны друг другуВторое конечно мене очевидно выглядит, но по функциональности разницы не вижу
x = x && (x = y)уже бред, поскольку происходит двойное присвоение, хотя оно тоже даст аналогичный результат. Вряд ли это то что будет под капотом.
Там нет никакого второго присвоения, прочитайте ещё раз:
x && (x = y)Вот эквивалентный код (за исключением возвращаемого значения):
if (!x) x = y;Лишнее присваивание как раз наблюдается в варианте x = x && y, потому что его эквивалент вот такой:
if (x)
x = x;
else
x = y;Эквивалентный код для
x && (x = y)-
if (x) x = y(видимо опечатка у вас, ! там явно лишний).
(видимо опечатка у вас).
Да, точно, почему-то в голове оператор || крутился.
В случае x = x && y есть одно присваивание, x = результат выражения x && y.Ну да, в этом-то и проблема — оно всегда одно и всегда делается, хотя в половине случаев оно избыточно, потому что сводится к x = x.
А во-вторых, 100% эквивалент был бы
Я написал же, что эквивалентный код я пишу без учёта возвращаемого значения
Да, спасибо, я тоже уже осознал, что "лишнее" имеется в виду "всегда" (в противовес только "в случае, если х не фолси") :)
Хотя конечно в современных реалиях напугать кого-то лишним присваиванием думаю не получится. Когда пишешь React, то твой собственный код часто вообще на производительность никак не влияет =) можно хоть биткойны майнить, всё равно хуже не будет.
Как по мне, лучше бы господа ЖСники подумали о том, как разобраться с WTFами, прежде чем микросахаром заниматься. Хотя, с другой стороны, проще просто взять другой язык. Вон уже и на питоне можно писать для веба.
Хотя конечно в современных реалиях напугать кого-то лишним присваиванием думаю не получится.
В описании пропозала автор объяснил, где это может быть полезно. В обычном присваивании это погоды не сделает, верно, но в случае объекта это может вызвать сеттер и там может быть более тяжелая логика (например, валидация или парсинг строки).
Как по мне, лучше бы господа ЖСники подумали о том, как разобраться с WTFами
Автор предложения занимается этим на общественных началах, поэтому претензии "лучше бы другим занялся" тут неуместны.
это может вызвать сеттер
ОМГ, ещё один ВТФ. Т.е. при одном присваивании сеттер вызывается, при другом — нет?
Автор предложения занимается этим на общественных началах
да у меня к автору предложения нет претензий. У меня вообще нет претензий. Я просто констатирую факт, что язык, который и так чемпион по ВТФам, вместо того, чтобы с ними разбираться, делают ещё более запутанным.
Т.е. при одном присваивании сеттер вызывается, при другом — нет
Не понимаю вашего удивления. При назначении свойств объектам можно вызвать сеттер:
const obj = {
set value(value) {
console.log(value, 'set!')
}
}
obj.value = 'something'; // здесь будет вывод в консоль
let value = 'something'; // а здесь ничего не будетТам нет никакого второго присвоения
А я и не утверждал, что оно в приведенном вами коде, оно в приведенном мною коде.
Лишнее присваивание как раз наблюдается в варианте x = x && y
Именно это я и имел виду, когда написал: "(второе делает меньше операций)"
Новые возможности ES2021 / ES12