a
А где спека на тс?
😅
Size: a a a
2020 August 25
a
тут возникает вопрос, где доверять, а где проверять? "не полагаться на него через чур сильно" - явной границы доверия нет ((
Относится к статической типизации как к сахару над юнит тестами
M
Проверять везде где и в жс же.
Например, там, где в библиотеку кормят входные данные, или где данные прилетают от юзера.
И там, где они используются и их тип критичен.
Например, там, где в библиотеку кормят входные данные, или где данные прилетают от юзера.
И там, где они используются и их тип критичен.
А вот как выдумаете что будет в том же Rust и serde json если ты будешь ожидать одну схему данных описанную в структуре а прилетит содершенно другая?) А что будет в таком же случае в Хаскеле? Какой бы нибыл строготипизированный язык, работа с IO должна осуществляться очень аккуратно с кучей проверок
НС
А вот как выдумаете что будет в том же Rust и serde json если ты будешь ожидать одну схему данных описанную в структуре а прилетит содершенно другая?) А что будет в таком же случае в Хаскеле? Какой бы нибыл строготипизированный язык, работа с IO должна осуществляться очень аккуратно с кучей проверок
Ну я и не говорил что не нужно а других языках проверять.
Но в тс надо это делать в сильно большем количестве случаев/мест чем в расте.
Но в тс надо это делать в сильно большем количестве случаев/мест чем в расте.
M
Вообще то во всех статически типизированных языках информация о типах не попадает в рантайм. Исключение только RTTI и рефлексия, которые не все языки обладают или они опцилнальны
M
Ну я и не говорил что не нужно а других языках проверять.
Но в тс надо это делать в сильно большем количестве случаев/мест чем в расте.
Но в тс надо это делать в сильно большем количестве случаев/мест чем в расте.
Так я же и говорю, что проблема в TS скорее это soundness и недостаточная строгость. Вот если у него будут номинальные типы, если при чтении из массива компилятор будет заставлять тебя проверять на null / undefined то есть возвращать тип T | undefined а не просто тип T для arr[index] то тогда будет намного лучше в плане защиты от рантайм ошибок, но в то же время внесет излишнюю вербозность как в Rust
НС
Так я же и говорю, что проблема в TS скорее это soundness и недостаточная строгость. Вот если у него будут номинальные типы, если при чтении из массива компилятор будет заставлять тебя проверять на null / undefined то есть возвращать тип T | undefined а не просто тип T для arr[index] то тогда будет намного лучше в плане защиты от рантайм ошибок, но в то же время внесет излишнюю вербозность как в Rust
А что про https://github.com/samuelgoto/proposal-optional-types думаешь?
M
А что про https://github.com/samuelgoto/proposal-optional-types думаешь?
Думаю что gradual typing для JS не нужен, Тем более в таком виде. Уж лучше dart. Ну или hegel. Но хегель очень сырой пока что
a
А вот как выдумаете что будет в том же Rust и serde json если ты будешь ожидать одну схему данных описанную в структуре а прилетит содершенно другая?) А что будет в таком же случае в Хаскеле? Какой бы нибыл строготипизированный язык, работа с IO должна осуществляться очень аккуратно с кучей проверок
в хаскеле, на сколько знаю, ты можешь работать с IO только через валидаторы, которые гарантируют тип
НС
А кмк даже проверки типов аргументов функций в рантайме, даже минимальные на примитивы, будут очень полезны в жс
a
Ну я и не говорил что не нужно а других языках проверять.
Но в тс надо это делать в сильно большем количестве случаев/мест чем в расте.
Но в тс надо это делать в сильно большем количестве случаев/мест чем в расте.
С gql не особо. С рестом можно runtypes какой-нибудь, а юзеринпут в основном затайпен
M
Никита, а не оффтоп ли все это здесь? Может лучше это обсуздать в чате по JS или Typescript?
НС
Никита, а не оффтоп ли все это здесь? Может лучше это обсуздать в чате по JS или Typescript?
Оффтоп, кажется. Давай забьём.
JD
(лучше не строить sql конкатенацией, но некоторые ормы не могут себе такое позволить, пример реальный)
У nearform был модуль, который строит sql на шаблонных строках, все проверки под капотом делает. Выглядит элегантно.
SR
2020 August 26
НС
Вышел Chrome 85.
Обзорное видео: https://www.youtube.com/watch?v=htAiPOarIwI
Изменений в нём довольно много, я писал о них ранее тут (DevTools Chrome 85), тут (Hoidini Properties and Values в CSS), тут (WebHID API и потоковые запросы Fetch), тут (что нового появилось в бете Chrome 85), тут (улучшения доступности PDF) и тут (
Также есть статья со списком устаревших и убранных фич: https://developers.google.com/web/updates/2020/07/chrome-85-deps-rems
Обзорное видео: https://www.youtube.com/watch?v=htAiPOarIwI
Изменений в нём довольно много, я писал о них ранее тут (DevTools Chrome 85), тут (Hoidini Properties and Values в CSS), тут (WebHID API и потоковые запросы Fetch), тут (что нового появилось в бете Chrome 85), тут (улучшения доступности PDF) и тут (
content-visibility: auto).Также есть статья со списком устаревших и убранных фич: https://developers.google.com/web/updates/2020/07/chrome-85-deps-rems
НС
НС
Csp bypass это (довольно) эпично
НС
Гораздо более серьёзная уязвимость была обнаружена некоторое время назад в Chromium. Она позволяла полностью обойти все CSP правила на любой платформе в браузерах Chrome, Edge, Opera и других на основе Chromium версий с 73 по 83. Для обхода CSP достаточно было указать
https://www.perimeterx.com/tech-blog/2020/csp-bypass-vuln-disclosure/
javascript: в атрибуте src айфрейма. https://www.perimeterx.com/tech-blog/2020/csp-bypass-vuln-disclosure/