Это называется Sound null safety и никакого отношения к моему комментарию не имеет. Речь о том, что значение null/nil/none все равно есть. Изначально я в ветке оспаривал это утверждение:
undefined не хуже и не лучше null, оба ИМХО не нужны в современной ЯП, но что поделать.
Тут все просто же. Если вы прочитали дисклеймер, то стоило просто прекратить чтение. Расписано подробно как раз для тех, кто нюанса не знает, а вот сравнение объектов через JSON.stringify - очень плохая идея:
const a = { id: 1, name: null };
const b = { name: null, id: 1 };
console.log(JSON.stringify(a));
console.log(JSON.stringify(b));
Не делайте выводов о моем понимании или не понимании, лучше спросите явно. Мой вывод основан на знании других языков программирования, которые прекрасно обходятся без этого типа.
И снова, здравствуйте. )) Мне кажется, подобную мысль в комментариях придется еще несколько раз повторить. Цель текста: обозначить имеющиеся подводные камни, на которые стоит обратить внимание, каким способом проблему решать - каждый выбирает сам для себя. Перебор ключей не используется для решения, я с его помощью лишь продемонстрировал тот факт, что наличие или отсутствие undefined-поля можно определить лишь по наличию ключа, но не по значению.Что касается рефлексии, то я тоже сторонник жесткого описания и проверки схемы, причем, как на стороне фронта, так и на стороне бекенда (от нарушения контрактов никто не застрахован). Возможно, в текст стоило включить упоминание того, что в старых фреймворках (без использования Proxy для реактивных свойств) невозможно отследить изменение свойства, если оно отсутствует в объекте (тот же Vue 2.x).
И что доказывает ваш пример? Что если объявить два разных объекта по-разному, что будет разный результат? Что мешает написать const example2 = { a: 1, b: undefined } as { a: number; b?: string }? К тому же, вы вновь аппелируете к TypeScript, когда речь в статье о JS.
Upd: извиняюсь, думал, что отвечаю предыдущему комментатору.
От того, что тип переменной динамический, не значит, что такая переменная не существует, это не одно и то же. Не знаю, о каком исключении на тип идет речь, я лишь говорю о том, что при попытке почитать неинициализированную переменную или несуществующее поле, гораздо логичней выбрасывать исключение. В случае с переменной это позволило бы автоматически снизить большое количество обидных ошибок, а для полей объектов есть способы проверки наличия поля.
Во-первых, про TS сказано почти в самом начале, а во-вторых, в том-то и дело, что "почти". И цель не показать - какие классные решения есть, а указать на нюанс языка, который нужно знать, и который имеет место быть.
Мне вообще ничего из этого боль не причиняет, но не раз встречал подобные проблемы у других на каком-либо этапе. Давайте будем честны, с дуру можно сделать много чего, но вероятность того, что разработчик по незнанию попытается сериализовать какой-нибудь Symbol сильно меньше, чем это может произойти с undefined-значением.
С точки зрения интерпретатора что desc?: string;, что desc: string | undefined равносильны, если подскажете способ различить эти определения, кроме как визуально - буду рад. Что касается различных схем, сериализаторов и так далее - ясно дело, что решения есть, правда, чем именно перегрузка toJSON может вам помочь мне неведомо, если вы имеете ввиду, что можно сериализовать undefined-поле как null, то это как раз далеко не то, что нужно, если конктракт подразумевает наличие опционального, а не nullable-поля.
Вы говорите о причинах, в тексте написано - как такой ситуации избежать (используйте null), но рассматривается вариант, который реально возможен и встречается в проектах. Оценки плохо/хорошо тут нет. Это может быть сторонняя библиотека, автор которой посчитал, что использование undefined вместо null - отличная идея. Ситуация может возникнуть в результате разных обстоятельств: функция, которая должна вернуть объект - вернула undefined, а мы записываем это значение в поле нашего объекта, и да, в таком случае, правильно было бы обработать этот результат, скажем так:
Собственно, цель статьи была обратить внимание на имеющиеся подводные камни. А ваша претензия звучит как "хорошо делай - хорошо будет". Да кто ж с этим спорит-то?
Не силен в функциональных языках, так что спрошу: если поле/переменная Optional, то каково будет ее значение, если там нет ничего? Разве не тот же null?
Насчет второго - поясните, позволю с вами не согласиться. null нужен, иначе как вы укажете на явное отсутствие значения, например, отсутствие объекта в переменной, который может там быть, а может и не быть.
Вы прочитали всю актуальную спецификацию ECMAScript? Но, в целом, да, и ремарка насчет игнорирования рекомендаций комитета на это намекает. Реальность не так идеальна, как нам хотелось бы.
Вам, батенька бы вникнуть в попытки решения подобной проблемы в NEXTStep задолго до появления этих ваших PowerShell, что не отменяет верности замечания. Идея использовать текстовый поток родом из 60-х годов прошлого века, не так уж удивительно, что решение неидеально и несколько устарело.
Собственно, про выбор инструмента под задачу уже много раз в комментариях сказали, я же хотел бы отменить один, как мне кажется, важный факт: база относительно легко перенеслась на РСУБД. Отсюда можно сделать предположение, что и построена она была исходя из принципов построения реляционных баз данных, коей MongoDB не является. Для нее нужно совершенно иначе нужно проектировать структуру базы, и тот случай, когда одна сущность у вас разбита на несколько документов и/или коллекций - вызывает большие вопросы. В общем, Mongo - это не про взял и начал писать, сперва неплохо хотя бы базовый курс по ней пройти, раньше бесплатный был, теперь - не знаю. С добавлением транзакций спектр применения значительно расширился, однако, сейчас, с учётом наличия поддержки массивов и JSON-полей с возможностью поиска по ним, Postgres для проекта с неизвестными конечными целями и перспективами роста можно считать наиболее привлекательной СУБД. Мое субъективное мнение.
В том-то и дело, что никакого факта не существует в данном случае. Сейчас volatile имеет смысл, пожалуй, только на МК. Прерывание может сработать, а может и не сработать никогда, что, конечно, на этапе компиляции неизвестно. Таким образом, программист явно требует от компилятора каждый раз при обращении к переменной читать ее значение из памяти, а не кешировать в регистре.
Это называется Sound null safety и никакого отношения к моему комментарию не имеет. Речь о том, что значение null/nil/none все равно есть. Изначально я в ветке оспаривал это утверждение:
Тут все просто же. Если вы прочитали дисклеймер, то стоило просто прекратить чтение. Расписано подробно как раз для тех, кто нюанса не знает, а вот сравнение объектов через
JSON.stringify- очень плохая идея:Не делайте выводов о моем понимании или не понимании, лучше спросите явно. Мой вывод основан на знании других языков программирования, которые прекрасно обходятся без этого типа.
И снова, здравствуйте. )) Мне кажется, подобную мысль в комментариях придется еще несколько раз повторить. Цель текста: обозначить имеющиеся подводные камни, на которые стоит обратить внимание, каким способом проблему решать - каждый выбирает сам для себя. Перебор ключей не используется для решения, я с его помощью лишь продемонстрировал тот факт, что наличие или отсутствие undefined-поля можно определить лишь по наличию ключа, но не по значению.Что касается рефлексии, то я тоже сторонник жесткого описания и проверки схемы, причем, как на стороне фронта, так и на стороне бекенда (от нарушения контрактов никто не застрахован). Возможно, в текст стоило включить упоминание того, что в старых фреймворках (без использования Proxy для реактивных свойств) невозможно отследить изменение свойства, если оно отсутствует в объекте (тот же Vue 2.x).
Дополню себя же: если пример с аннотацией не очень удачен, то можно попробовать прочитать свойство, которого там нет из словаря:
И что доказывает ваш пример? Что если объявить два разных объекта по-разному, что будет разный результат? Что мешает написать
const example2 = { a: 1, b: undefined } as { a: number; b?: string }? К тому же, вы вновь аппелируете к TypeScript, когда речь в статье о JS.Upd: извиняюсь, думал, что отвечаю предыдущему комментатору.
Вы сами придумали этот вывод? В тексте так и написано, что типа
undefinedнет в JSON. Зачем писать комментарий, если невнимательно прочитали?Это шутка такая? Чем
Noneотличается отnull? В C++ естьnullptr, к примеру, а в Go -nil.Python с вами не согласен
От того, что тип переменной динамический, не значит, что такая переменная не существует, это не одно и то же. Не знаю, о каком исключении на тип идет речь, я лишь говорю о том, что при попытке почитать неинициализированную переменную или несуществующее поле, гораздо логичней выбрасывать исключение. В случае с переменной это позволило бы автоматически снизить большое количество обидных ошибок, а для полей объектов есть способы проверки наличия поля.
Во-первых, про TS сказано почти в самом начале, а во-вторых, в том-то и дело, что "почти". И цель не показать - какие классные решения есть, а указать на нюанс языка, который нужно знать, и который имеет место быть.
Мне вообще ничего из этого боль не причиняет, но не раз встречал подобные проблемы у других на каком-либо этапе. Давайте будем честны, с дуру можно сделать много чего, но вероятность того, что разработчик по незнанию попытается сериализовать какой-нибудь Symbol сильно меньше, чем это может произойти с undefined-значением.
С точки зрения интерпретатора что
desc?: string;, чтоdesc: string | undefinedравносильны, если подскажете способ различить эти определения, кроме как визуально - буду рад. Что касается различных схем, сериализаторов и так далее - ясно дело, что решения есть, правда, чем именно перегрузка toJSON может вам помочь мне неведомо, если вы имеете ввиду, что можно сериализовать undefined-поле как null, то это как раз далеко не то, что нужно, если конктракт подразумевает наличие опционального, а не nullable-поля.Вы говорите о причинах, в тексте написано - как такой ситуации избежать (используйте
null), но рассматривается вариант, который реально возможен и встречается в проектах. Оценки плохо/хорошо тут нет. Это может быть сторонняя библиотека, автор которой посчитал, что использованиеundefinedвместоnull- отличная идея. Ситуация может возникнуть в результате разных обстоятельств: функция, которая должна вернуть объект - вернулаundefined,а мы записываем это значение в поле нашего объекта, и да, в таком случае, правильно было бы обработать этот результат, скажем так:Собственно, цель статьи была обратить внимание на имеющиеся подводные камни. А ваша претензия звучит как "хорошо делай - хорошо будет". Да кто ж с этим спорит-то?
Не силен в функциональных языках, так что спрошу: если поле/переменная Optional, то каково будет ее значение, если там нет ничего? Разве не тот же
null?Насчет первого - нет, это не проблема библиотеки.
Насчет второго - поясните, позволю с вами не согласиться.
nullнужен, иначе как вы укажете на явное отсутствие значения, например, отсутствие объекта в переменной, который может там быть, а может и не быть.Вы прочитали всю актуальную спецификацию ECMAScript? Но, в целом, да, и ремарка насчет игнорирования рекомендаций комитета на это намекает. Реальность не так идеальна, как нам хотелось бы.
Никакой ошибки при первичном переводе его фамилии не было, просто была применена не транслитерация, а транскрипция.
Вам, батенька бы вникнуть в попытки решения подобной проблемы в NEXTStep задолго до появления этих ваших PowerShell, что не отменяет верности замечания. Идея использовать текстовый поток родом из 60-х годов прошлого века, не так уж удивительно, что решение неидеально и несколько устарело.
Собственно, про выбор инструмента под задачу уже много раз в комментариях сказали, я же хотел бы отменить один, как мне кажется, важный факт: база относительно легко перенеслась на РСУБД. Отсюда можно сделать предположение, что и построена она была исходя из принципов построения реляционных баз данных, коей MongoDB не является. Для нее нужно совершенно иначе нужно проектировать структуру базы, и тот случай, когда одна сущность у вас разбита на несколько документов и/или коллекций - вызывает большие вопросы. В общем, Mongo - это не про взял и начал писать, сперва неплохо хотя бы базовый курс по ней пройти, раньше бесплатный был, теперь - не знаю. С добавлением транзакций спектр применения значительно расширился, однако, сейчас, с учётом наличия поддержки массивов и JSON-полей с возможностью поиска по ним, Postgres для проекта с неизвестными конечными целями и перспективами роста можно считать наиболее привлекательной СУБД. Мое субъективное мнение.
А для продакшена вообще `npm ci --production`, что часто существенно снижает размеры образа.
В том-то и дело, что никакого факта не существует в данном случае. Сейчас volatile имеет смысл, пожалуй, только на МК. Прерывание может сработать, а может и не сработать никогда, что, конечно, на этапе компиляции неизвестно. Таким образом, программист явно требует от компилятора каждый раз при обращении к переменной читать ее значение из памяти, а не кешировать в регистре.
Возможно, комментатор хотел сказать, что стоило назвать горутины сопрограммами, хотя принципиальной разницы тут никакой.